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ABSTRACT 

A new notation is introduced for representing real-time 
scheduling at the task, and event level. These schedules are called 
control stru ctu res. The primary constructs included which direct the 
flow of control are sequencing, iteration, and preemption. Additional 
notation allows the representation of interrupt masking, task 
termination by iwtwy**! events, task restart as well as resumption 
from the point of preemption and codestripping. Algorithms are given 
for finding the preemption structure of a given control structure in 
the notation. 

The types of representable control structures are classified by 
the topology of their Control Flow Graphs. It is shown that although 
branching is allowed in the preemption structure, a tree-shaped 
preemption structure cannot be represented. Both partial and total 
orderings of tasks and interrupt priorities are supported, however. 

A terminology for describing real-time properties of control 
structures is developed, and it is seen thai without certain assumptions 
about task execution times and event timings, cannot be 

drawn regarding real-time performance of a control structure. A series 
of algorithms is presented "which make use of these assumptions, and 
find values for task execution times in the presence of preemption. 
The algorithms can analyze control structures containing the principal 
control features; suggestions axe given for further development of 
algorithms which can analyze any representable control structure. 
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1: Introduction 

In an article entitled "Toward a discipline of real-time programming" [Wirth 
77b], Nlklaus Wirth has divided programming Into three categories based on the In- 
creasing complexity of validating their programs: 

1 . Sequential programming 

2. Multiprogramming 

3. Real-time programming 

In a real-time system, a program may be attempting to control or to react to 
certain external processes which cannot be forced to cooperate with programmed 
processes through use of a synchronization primitive such as a semaphore [Dljkstra 
68] or a monitor [Hoare 74]. In order to coordinate Itself with these external, 
non-programmable processes, the real-time program must know something about its 
own execution speed. Thus its correctness will be dependent on the speed of the 
processor on which It is run; but this is not a property of' the program Itself; Wirth 
Identifier this as tiie essentia) distinguishing feature of real-time programming. 

This thesis does not directly address fine tesiie of validating i real-time programs. 
Instead, it deals wrtii ti*e representation of schedules for real-time programs called 
eor&mt structuras, and some aspects of measuring real-time properties of the 
resulting control structures. In the sense that knowledge of these real-time proper- 
ties may be a prerequisite for validation of a reaMfme "programV ti%e work presented 
here dees represent a contrtoutkjn to one aspect of the vaBdatibn problem. 
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Introduction Section 1 

1.1: Related Research 

Most of the previous studies In the field of real-time programming have been 
centered on one of two major areas, the design of languages for real-time program- 
ming, and scheduling to meet real-time deadlines. 

The development of languages for real-time programming can be split between 
two approaches; the extension of existing languages [Benson 87; Freiburghouse 
77; Ormicki 77; Phillips 76; Wirth 77a], and the creation of entirely new languages 
tailored to the requirements of real-time programs fMennessy 76; Kieburtz 76; 
Schoeffler 70]. The essence of these efforts has been to provide some interface 
between the real-time program and the scheduling of itself and other programs, ei- 
ther through access to the processor's interrupt system, clocks and/or timers, or 
by influencing the processor's scheduling routines. Such features provide only a 
low level capability for determining a process' reel-time behavior; in some cases It 
may be possible to think of all the timing interactions that* could impact on the 
correctness of a real-time system, but the burden of doing so has usually fallen 
most heavily (and often totally) on the programmer. Decisions ae baste a* assign- 
ing priorities to different tasks must typically be made by manual analysis, in the 
hope that nothing has been overlooked. As the sLze of tb* system increases, the 
complexity of the problem grows as we U, until manual analysis becomes extremely 
tedious and error-prone. If not impossible. 

Ideally, a programmer could submit his real-time response requirements along 
with his programs* and either have them scheduled appropriately, or be tow that Wa 
requirements cannot be met by that particular system. Some systems (such as the 
CONSORT system of the Domain Specific Systems Research group at MIT) have 
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been developed which can do this for a limited class of programs, but to the 
author's knowledge no one has yet created a system *e do this ta general: Howev- 
er, considerable research has been done on scheduling tasks In the presence of 
hard real-time deadlines. 

Most of the significant results obtained have been based on restricting atten- 
tion to limited classes of control structure types. For example, kt a multiprocessor 
environment where there is a partial ordering of tasks but no Iteration outside of 
tasks, [Manacher 67} give* an algorithm which WW construct near-optimal task VStS 
(execution orderings) for almost any combination of task run times and deadRhes. 
If the schedule Is fuH to capacity with tasks wliose completion times are 
guaranteed, his strategy allows the system' to take on addH^al unguaranteed 
tasks without affecting the guaranteed status of those tasks already scheduled. 
His scheme does not consider the effects of pr oomptlof i, however. Berlin [SerHn 
72] and Uu and Layland [Uu 73} have independeotiy studied the problem of 
scheduling tasks which are iterated but have rw relative or d ering s. SerMn gives 
scheduling algorithms based on fixed priorities, time slicing, and relative urgency. 
The last is a dynamic priority scheme, where the processor re-evaluates the priori- 
ties of esch task at every interrupt, and selects for execution the one with the 
earliest deadline. This method is shown to produce a schedule which meets real- 
time deadlines if any schedule will, but SerHn's analysis neglects the overhead of 
context switching. 

A different approach is taken by [Hennessy 75; Kieburtz 75] in their micropro- 
cessor language TOMAL; instead of using an interrupt system, they have a com- 
piler insert calls to a task control monitor (which Is created along with the compile- 
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tion of « set of programs) at specific points In the compiled code. This provides 
assurance that the task control nonltor wit get contra* within s finite and bounded 
interval, after each oodastrip, as the code between monitor cans is named. This is 
similar to a time slicing system which allocates execution time in fixed amounts to 
each task, but the time sflces are synchronized with program execution. The 
length of the codestrip is determined by the response time requirements of the 
task, and the compiler &un determine whether the pro grammer supplied requtre- 
ments are in conflict. The notation given in this thesis has the capability of 
representing codestiips. 

A work which is related to the present one and in fact complementary is tiiaf 
of Teixeira [Teixeira 78} Much of the terminology used hern was developed 
there, partkuaarty that of Chapter 6, where algorithms for measurtng reaMime pro- 
perties are developed. Teixeira also used the regular expressfon notation of 
Chapter 2 to denote sequencing and rteration Of tasks. Mm study centers, howev- 
er, on finding schedules to meet reertime constralntsr tiie orientation of tile 
present work m described in the foiiowtng section. 

1 J2i Objectives 

The principal goal of this research is twofold; to develop a convenient 
representation for real-time control structures, and to demonstrate how such a 
representation is useful as a basis for analyzing real-time properties for specific 
control structures. 

The representation as developed models control structures at the task and in- 
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terrupt level; the tasks are assumed to be serf-contained program units whose ex- 
ecution time is bounded, and interrupts are represented aa occurrences of event 
variables. The event variables could -be used to represent any event however, 
which might be synchronous or asynchronous with respect to the executing task. 
The notation can represent total and partial orderings among its tasks, and iteration 
of tasks at a single priority level or across several priority levels. As weH as 
representing conventional single and multi-level Interrupt structures, the control 
structures given here can represent several unconventional preemption structures, 
including branched structures where each branch has aj* individual preemption 
structure which may itself be branched. 

As well as representing this basic framework, the capability is provided to 
represent: t > t 

1 . Codestripping as previously described. 

2. External termination of a task or group of tasks by an event 
occurrence (as opposed to temporarily preempting them). 

3. Indication that a task or group of tasks Is not preemptible by 
a set of events. -/-■•..;■ ?■■•■■- 

4. The choice between restarting a preempted task or group of 
tasks from the beginning vs. resuming execution from the point of 

Thus a rather general notation is given, which in addition represents ail of this in- 
formation rather compactly. The notation may be used in any application where it 
Is necessary to communicate something about a control structure of this sort, be it 
human to human, human to machine, or machine to machine. In the second case, 
the specific applications In mind are representation of a control structure for 
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analysis, and for describing tea reaMime system what sort of control structure It 
should establish for a set of tasks with real-time constraints. In this vein, the no- 
tation is quite independent of machine architecture; and thus a subset of the 
language can be chosen for a target machine which supports the control features 
included therein. 

This leads into the second goal of the Investigation, which Is to demonstrate 
how algorithms can be developed which ascertain real-time properties for control 
structures of the language. There are several tNne Intervals which are probably of 
common interest to a large segment of users of real-tome programs, such as: 

1. The maximum delay between the occurrence of an event and 
the initiation of Its program. 

2. The maximum time required to execute a set of tasks at a 
given priority, with preemption. 

3. The maximum time that may elapse without there being an ex- 
ecution of a given set of tasks. 

This is not intended to be an exhaustive survey of real-time properties, but rather 
an Introduction to the usage of the notation as the foundation for such analysis. 
Indeed, it is likely that each reahtime system, baa,- its ow* special requirements and 
characteristics; it is hoped that an appropriate subset of the language can be 
chosen to model those characteristics, and algorithms developed which are suited 
to an application's special needs. In addition, many applications will have natural 
restrictions which lead to simpler algorithms; It is with intent of illustrating this 
point that several special case algorithms are developed. 
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1 .3: Outline of the Thesis 

The next chapter presents a cortfsxt free grammar Iw sthe control structure 
language, as well as giving the semantics for each construct. Sequencing, iteration 
and preemption are the principal features, with extensions added as described in 
Section 1.2. Methods of determining the overall preemption structure of a control 
structure are also presented. 

Having introduced the notation, Chapter 3 presents the concept of a Control 
Flow Graph (CFG) [Allen 78; Fosdick 76], which gives a graphic representation for 
the paths of control flow dictated by a given control structure. A definition of ab- 
solute priority levels Is derived Effort a controf structure** CFG Trepreseritatlon. Then 
a classification of control structure types representable by the notation is given, 
based on the topology of ffiefr^CFG** in addition, some types of control structures 
which are not representable are described. ^* > e- 

A terminology for real-time properties of control structures te developed In 
Chapter 4; the requirements for knowing certain things about event timings In ad- 
vance is also discussed here. 

This leads into Chapter S, where a hierarchical series of algorithms is present- 
ed which are designed to find the worst cases for some of the real-time properties 
of increasingly complicated classes of control structures. The most general algo- 
rithm given is applicable to the set of control structures which includes the basic 



framework of sequencing, iteration and preemption. The types of modifications 
which would be required to analyze any repress 
cussed, although detailed algorithms are not given. 



which would be required to analyze any representable control structure are dls- 
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2s A Notation for Real-time Control Structures 

2.1: Introduction 

In this chapter a notation for representing real-time control structures wilt be 
developed. The intention is to provide a general analytical tool which will be suit- 
able for representing most of the possible ways to share a processor among the 
members of a set of tasks. This will include: 

1. Sequencing: a total ordering of tasks to ba executed. 

2. Iteration: cyclic execution of some ordered set of tasks. 

3. Preemption: a partial ordering of tastes where the^oBcuwence 
of an event forces termination of execution of the currently run- 
ning task and starts execution of a naai task. . ; * 

A context-free grammar will be developed to define t*» syntax of the representa- 
tion, it is summarized in Appendix A. 

2.2: The Basic Control Structure 

The real-time system to be represented is modelled as a set of procedures to 
be run, called tasks, a control structure which specifies the order (or possible ord- 
ers) In which the tasks may be run, and a processor which executes the tasks ac- 
cording to the scheduling constraints specified by the control structure. 

Thus the flow of data between tasks, if there is any, need not be a concern; 
It is assumed that any execution ordering needed to preserve the intended seman- 
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tics of the computation (data flow) will be embodied In the control structure. For 
example, If an output of task A is an input of task f,^iea e |ha QontspJ §fruc*ure as- 
sociated with their execution should ensure that task A completes execution be- 
fore task B begins. 

Further, the detailed flow of information and control within a task, i.e. among 
Its Internal variables and Instructions respectively, need not be of concern either. 
It Is only necessary that an upper bound m #» texecution tim% of a task be esta- 
blished; this Is discussed further In Section 4.2. 

A task will be represented by a task Identifier ("<task id>"), which In most of 
the examples will be a single capital letter (though it need not be). Figure 2.1 
shows the grammar which defines task Identifiers. 

<task ld> ::« <ietter> | <task id> <alphanumeric> 
<tatter> :s« A ] B f C j ... | Z 
<alphanumerlc> ::= <letter> | <digft> 
<dlgit> ::= | 1 j 2 | ... I 9 

Ffg. 2.1. Syntax for task identifiers. 

Next to a single task, the simplest thing to represent is the sequencing of two 
or more tasks which are totally ordered. This is done in the natural way, by listing 
the task Identifiers in the order of execution of their corresponding tasks, separat- 
ed by blank spaces for parsing. A string of one or more tasks wHi be called a 
basic control structure, or <basic cs>. Note that it is permissible to nst a task jd 
more than once in a <feo*Ic es>, to represent the situation 'where the corresponding 
task is executed more then once with zero or more other task executions 
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sandwiched In between. 1 The syntax is: 

<baste cs> ::* <task W> J <baste cs> » <task id> 

where "H" represents the blank space terminal symbol 

The simplest control structure is Just a basic control structure: 

< control structure> ::= <bastc cs> 

Thus the grammar gh/en so far to sufficient to represent single task execution and 
sequenced task execution control structures. 

2^t How of Control 

It is useful to formalize the notion of control flow with respect to control struc- 
ture execution. The processor follows the "instructions" supplied by a control 
structure, doing both "applications-oriented" work (when rt is actually executing the 
statements of a task), and "systems-oriented" work (when it is determining which 
task to execute next according to the constraints embedded jn the control struc- 
ture). In either case, the actual machine instructions being, executed at any time 
wiH be associated with a particular symbol in the control structure representation; 
It wffl be said that at that time the locus of control (abbreviated LC) is at that 
symbol. For example, in the following control structure: 



1. Every occurrence of a task id in a control structure represents a separate in- 
stantiation of that task, with its own private state. This is wed to modal reen- 
trantiy coded routines. 
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AB 

when Instructions of task A are executing, LC is at A; when instructions of task B 
are executing, LC is at B. 

2.4: Closed Control Structures 

It is desirable to introduce parenthesization for the grouping of task id's in the 
natural way. In particular, this will be needed to Indicate the scope of the various 
special symbols which will be used for Iteration, preemption, etc. It will also be 
helpful in constraining the class of legal control structures to exclude nonsensical 
ones, such as those In which some tasks can never execute,, regardless of preemp- 
tion timing considerations. Parenthesized (sub-)control structures will be called 
closed control structures, and the class will be added to as necessary for addition- 
al representational power. At the top level, closed control structures will be includ- 
ed in the set of legal control structures. Figure 2.2 gives the syntax for closed 
control structures; a syntax is also given for closed control structure lists, which 
will be needed later to represent more complex control structures. 

<control structure> ::= <basic cs> | <closed cs> 

<closed cs> ::= «basic cs» | (<ctosed cs> <basic cs» J« closed cs list» 
<closed cs list> ::= (closed cs> | <cloS8d os Hst> <dosed cs> 
Rg, 2.2. Syntax for olosed control sinictures. 
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2.6$ Iteration 

Most real-time process control applications require the periodic repetition of a 
certain task or sequence of tasks. Borrowing from the notation of regular expres- 
sions, the asterisk is used to Indicate a endless repetition of a control structure, 
its BMP: 

<ltsrative cs> ::* <basic cs>" | <closed cs>" | <bastc cs> Oterative cs> 

The use of """ is most easily explained by examples: 

AB« £ MB)* =A BBBBB .„ 
(AB)»5 AB ABAB- 
From a flow of control viewpoint, when LC reaches ah asterisk following a right 
parenthesis, ft returns to the matching left parenthesis. If ft reaches an asterisk 
following a task Id, It repeats that task. 

The final expansion of the top-level deflrtftJon of control structure IS: 

< control structure> ::= <basic cs> | <ctosed cs> j <lterative cs> 



2.6: Preemption 

2.6.1; Pr ssm p MM o Control Streetwros 

With the class of con^ol stnicturee deined so f ar, Jthe ertly execution se- 
quences possible are those hi which the order of task execution is entirely 
predetermined (static). In many situations, a processor wM need to respond to 
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asynchronous events such as Interrupts, which may not occur at predictable times. 
It may be, desirable to nave such events trigger the tf^BcetlcW of a different part 
of the control structure than was previously tn control. Informally, this wlfl be 
modelled by placing sub-control structures Into the overall control structure fh" order 
of non-decreasing priority. Demarcation of the priority levels is achieved by indi- 
cating that a control structure is preemptible. Figure 2.3 gives the syntax for 
preemptible control structures. Preemption Is initiated by occurrence of a particu- 
lar event (which may be complex), 1 so an event variable is Included which stands 
for the event. 

preemptible cs> ::= <controJ structure^ / <event var> 
< event var> ::= e<integer> 
<integer> ::= <diglt> | <integer> <dJgit> 

<closed cs> ::= «basic cs>) | «closed cs> <basic cs» j «closed cs llst» | 
(<preemptible cs» | «closed cs> preemptible cs» 

Fig. 2.3. Syntax for preemptible control structures. 

Consider the following simple example, which models a control structure with a 
single level of interruption: 

The Interpretation of this control structure Is that A rims repeatedly until event el 



1. The event variable itself is not complex, but it may represent a complex event. 
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happen*; this initiates 8, which executes once; then tc returns to A*. 

The next section win describe how nor* complex control structures are 
represented (using the above syntax), such as those having multiple tevete of 
Interruption. 

2.6.2s Multiple Priority Level Control Struoturas 

Informally, event variables tie at the Interface between control structures of 
different priority, the control structure to the left of the "/<event var>" construc- 
tion having the lower priority. If LC is in the lower priority control structure when 
the event happens, it wftt move to the control structure Immediately to the right of 
the event variable. 

Thus a control structure with three priority levels might appear as: 

(((((A B)V*1)C D)/e2)E)» 

The preemption structure (for each event, the tasks which It msy preempt) is fairly 
straightforward here; el preempts A or B, ©2 preempts A, 8, C or D. But the nota- 
tion is capable of representing more complex control structures, and a method of 
precisely determining the preemption structure is needed. 

The "Interrupts" or "preempts" relation is transitive; if e1 Interrupts A, initiat- 
ing C, and C Is interruptible by e2, then A f* kiterruptlbJe by e2. Moreover, all 
tasks of a single basic control structure wiH run at the same priority level, so basic 
control structures csn be considered ss units, rather than examining the preemp- 



1. Although a later section wW introduce the capability of masking specific Inter- 
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tion of individual tasks. 1 

The "Interrupts" fetation win now be fortWeflifd, Id. tt will be established clear- 
ly for each event in a control structure which basic control structures it may 
preempt. The set of tasks which are interruptlble by a certain event will be re- 
ferred to as the scope of that event. The "interrupts" relation for a control struc- 
ture will be represented by a Boolean matrix I with n rows and columns, where n is 
the number of baste control structures in the control jrtructure being analyzed. A 
single basic c* is associated wt» each row 7 anW cotmrf i, ti$ H $ j $ n. The 
basic cs associated with row (and column) / wffl be referred to il "basic cs /." 

The first event to the left of each baste cs wiH bo called that basic cs's Ini- 
tiating event. If l[7,/] = 1, it means that basic cs / runs at a higher priority than, 
basic cs j; in particular, it means that basic cs fs Initiating event can preempt 
basic cs j. The matrix I is computed according to the algorithm given in Figure-2.4. 
This matrix specifies which events cause preemptions across the bpr«Jer 
between adjacent priority levels. Since the "interrupts" relation is transitive, the 
transitive closure of this initial relation '** the complete preemption structure; this" 
specifies, for each event in the control structure, exactly which basic cs's it can 
preempt. Computing the transitive closure of the relation represented by \ Js 
straightforward. Let 1+ be the transtttve closure of I. Then 1+ "■ I + I 2 + ... + | n , 
where + is normal matrix addition. Boolean matrix nu4tlpttc*t»on is performed like 
regular matrix multiplication except 'AND' is substituted for 'TIMES' and 'OR' for 



rupts white a particular task is executing. 
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Algorithm 2.1» 

1. Let o be the number of basic ceV In the control structure. As* 
socfete a unique Integer from 1 to n with eech basic ea. 

2. Initialize I to be *n nxo matrix of zeroea. 

3. For each basic cs /, do steps 4 and 6. 

4. If basic cs / has no Initiating event, leave row / of I equal to 
ail zeroes, 

6. If basic cs / has an Initiating event o # And the control struc- 
ture Immediately preceding the construction Vs." Call this "con- 
trol structure *." By the syntax of. pr> wi»tiN a oootgof structures, 
control structure % wW be either a baste, closed or Iterative cs. 
For each bask: cs JtJn control structure A, est f /^) equal to 1. 

Fig, 2*4, Computing the matrix I. 

•PLUS*. 

Consider an example of a control structure which contains preemptible control 
structures, and which can be used to illustrate the construction of the "Interrupts" 
relation: 



Example 2.1. 



«(((a s)»yei ycvi9zmn9am» 



Notice that this control structure contains four basic control structures, A B, C, D 
and E. the InrUettng events for these basic cs's are as specified in Figure 2.5. 

. i : j i mm i . i up i i »,jN,l.Jj..|sn^ i| ^ :'"jj '' "*W *! " 



Ba sic CS . 

^l . l. i J T H! » m 



A> 
C 


E 



lntt J«fo» E %^, r R ^/gfl t !f Wn ..^J 



none 
el 
e2 
e3 



1 
2 
3 
4 



Fig. 2.6. Initiating events for Example 2.1. 



The matrix I is formed following Algorithm 2.1, and it appears In Figure 2.6. 
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1 . A B has no initiating event, so row 1 = [O 0] 

2. C's initiating event is e1. The control structure preceding e1 
is (A B)«, which contains the basic cs A B. Tfcue l£2,1] := 1. 

3. D's initiating event is e2. The control structure preceding e2 
Is ((A B)*/e1)C)* which contains the basic cs'a A B and C. Thus 
l[3,1] := 1 and I[3,2] := 1. f 

4. E*s initiating event is e3. The control structure preceding e3 
is D. Thus (4.3J :■ 1. 



I 


AB 


C 


D 


E 


AB 














C 


1 








9 


D 


1 


1 








E 








1 






Fig. 2.6. The I matrix for Example 2.1. 

Now, to get the overaH preemption structure, compute H, the transitive closure 
of I, as shown In Figure 2.7. 



1+ 


AB 


C 


b 


E 


AB 














C 


1 











D 


1 


1 





b 


E 


1 


1 


1 






Fig. 2.7. 1+ for Example 2.1. 



The preemption relations of the control structure are summarized in Figure 2.8. 
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LCat 


Preemptible by 


Initiate* 


Aor# 


et 


C 


A or B 


e2 ■ 





A or 8 


•3 


E 


C 


•2 


t> 


C 


e3 


E 





e3 


E : "- 


E 


none 


none 



FH|. 2.8. Preemption structure for Example 2.1. 

2.8.3: Occurrence of Event* 

The notion of an event "happening" la purposefully left vague; each applica- 
tion of the notation can attach Its own meaning. ; For the purpose st hand it is 
sufficient to assume that an event variable Is Wee « Hag? which gets set when its 
associated event occurs. The processor checks aN the event variables before be- 
ginning execution of every instruction. The following infernally describes what nap- 
pens if any flag is found to be set: 

1. In the case where LC is to the right of the event variable 
which has been set, no immediate effect on execution of the 
currently running task results. The cujre/itly running task is of a 
higher priority than that which Is requesting the interrupt. 

* ,~ . •■■-■.! 

2. The event variable remains set until such time as LC is to the 
left of it and in a baste cs which is preemptible by it, at which 
time It wttl cause a p reem p ti on. 

3. If more than one event corresponding to event variables to 
the right of LC has happened, then the rightmost one represents 
the highest priority interrupt (request), and LC moves to the right 



1. Generally, a queue of requests Is associated with a given event variable, so 
that additional occurrences of the event wW be remembered if they occur before 
the Initial occurrence is noted by the processor. By specifying a length for this 
queue, a system which remembers sn arbitrary number of event occurrences can 
be modelled. 
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of it (assuming, of course, that LC was within a basic cs preempti- 
ble by the event). 

4. Completion of the control structure at a given priority "resets" 
the event variable which triggered its execution; note that this 
must be done at completion rather than at initiation so that if the 
control structure Is preempted before it completes, then LC will 
return to it when it is once again the highest priority control 
structure requesting processor service. 



2.6.4: Substructure at a Single Priority Level 

A useful extension to the scheme is to provide for arbitrarily many control 
structures to reside at the same priority level, but to be initiated by different 
events. During execution of one of these control structures, occurrence of events 
In the other(s) at the same priority level will have no (preemptive) effect. The 
principle syntactic change is to allow replacement of an event variable by an event 
coupled //st, as shown in Figure 2.9. 

preemptible cs> ::= <control structure> / <event list> 
<event list> ::= <event var> | Uevent coupled list» | 

«event coupled list>)* 
<event coupled list> ::= <event var>: <control structure> | 

<event coupled list> '|' <event var>: <control structure> 
where '|' means the terminal symbol |. 
Fig. 2.9. Syntax for event coupled preemptible control structures. 



1 . Of arbitrary complexity, e.g. there may be additional local priority structure. 
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Consider an example: 



(A*/(e1i B | e2: C))* 



Preemption rights are as follows: 



LC at 


Preemptible by 


Initiates 


A 

A 

B or C 


e1 

e2 

none 


B 
C 



Execution of B or C continues uninterrupted to termination. Termination of B or C 
returns LC to A (unless el or e2 has happened again). 

A slight modification m the position of the terminal *"* leaves the interrupt struc- 
ture the same but results In different behavior on termination of B or C: 

(A*/(e1: B je2: C)*) 

The idea here is that once either B or C has been initiated (through occurrence of 
e1 or e2, respectively), control is never again returned to A. Instead, B and C will 
be executed every time e1 or e2 occurs. 

2.6.5: Determining the Interrupt Structure 

Since arbitrary control structures may reside in an event coupled list, it follows 
that such structures may contain additional events (or event coupled lists) which 
trigger even more deeply nested control structures. 

This ability to nest control structures raises a new semantic issue; what 
should be the scope of events which are not at the top levet in Ae event coupled 
list? The choice made here is to let any event In an event coupled list have the 
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same scope external to the event coupled list that an event variable would have if 
it were substituted for the event coupled list. Consider the following: 



Example 2.2. 



(A/(e1:((B/e2)C)|e3:((D/e4)E)))» 



The scope of e1, e2, e3 and e4 external to the event coupled list 
(e1:((B/e2)C)|e3:((D/e4)E)) is the same as that of e5 in: 

(A/e5) 

namely, the control structure to the left of the slash in the construction "/(<event 
coupled llst>)". 

The initiating events, as shown In Figure 2.10, are determined as before: the 
first event variable to the left of each basic cs. The interna! scope of the event 
variables is somewhat different, though. Events In event coupled lists may not 
preempt any task in the list which is separated from the event by a "|". Thus in 
the above example, e3 and e4 may not preempt B or C. Therefore Algorithm 2.1 
must be modified to reflect this. Figure 2.1 1 shows the resulting algorithm. 



Basic cs 


Initiating event 


A 


none 


B 


e1 


C 


e2 


D 


e3 


E 


e4 



Fig. 2.10. Initiating events for Example 2.2. 
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Algorithm 2.2s 

1. Let n be the number of basic ce?» in She control structure 
under examination. Associate a unique Integer from 1 to n with 
each baste cs. 

2. InitiaMze I to be an nxn matrix of zeroes. 

3. For each basic cs /, do steps 4 and 6. 

4. If basic cs / has no Initiating event, leave row f of f equal to 
aft zeroes. 

6. If basic cs / has an initiating event e, then this event appears 
in either a »/e" construction or a "|e" construction. 

a. If e appears In a "/e" construction, call the 
control structure immediately preceding "7e B 
"control structure A." For each baste cs J In con- 
trol structure *, set (/J3 equal to 1. 

b. If e appears In a ■fa* construction, then e 
cannot preempt any other basic cs's In the 
event coupled list of which ft Is a member, its 
scope starts at the control structure to the left 
of the V" ftt the construction "/(<event coupled 
Hst»". This will be the control structure 
preceding the first unmatched teft parenthesis 
to the left of e. Call this "control structure A." 
For each basic cs / In control structure k, set 
(/J] equal to 1. 

Fig. 2.11. Computing I for cs's containing event coupled lists. 



The control structure of Example 2.2 has the following preemption relation- 
ships: 



LC at 



A 
B 
C 
D 

E 



Preemptible by 



el, e2, e3, e4 

e2 
none 

e4 
none 



-23- 



Determining the Interrupt Structure s : Section 2.6.6 

Since two or more tasks may reside at the same priority level, such as B and C 
above, a natural question arises; what happens if both e1 and e3 occur "simultane- 
ously," at least within the resolution of the interrupt system. 1 Most systems adopt 
some arbitrary metric to resolve such situations. A typical one is the distance of 
the interrupting device from the CPU. A simitar approach is taken here. If more 
than one event is found to have occurred at the same priority level, then control is 
arbitrarily given to the first (leftmost) one in the event coupled list. 

However, with the addition of event coupled lists, "forks" are Introduced Into 
the preemption structure, as shown in Figure 2.12. A diagram such as this is called 
a Control Flow Graph, and win be defined formally and used extensively in the next 
chapter. For now It is sufficient to note that this diagram "unravels" the preemp- 
tion structure so that the relative priority levels of each task are displayed. If two 
or more events happen together, priority Is given to the event which initiates the 
task having higher priority, as was done before. In the above example, if e1 and 
e4 happen simultaneously control is given first to E (which e4 initiates). 



A 

m 

•1/ ivu.. 
/ I \ 

I / \ I 

e2] e2 e4 Je4 
| A \f 

C E 

Fig. 2.12. Preemption structure for Example 2.2. 



1. Typically the presence of Interrupt requests wHI be checked for once jper ln- 
structtan cyc4e, so any Interrupts happ«hfrig between two such chocks will be Indis- 
tinguishable as to their ordering In time. 
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2.7 j Mori-preemptible Tasks 

It Is occasionally necessary to perform all or some subset of a control structure's 
tasks in a non-preemptible mode, even though in the tatter case other tasks at that 
priority level may be preemptible. Simply indicating that a task is non-preemptible 
is equivalent to saying that the interrupt system is "turned off" while that task is 
In execution. For generality, the notation aflows as an alternative the specification 
of exactly those events which are not allowed to interrupt the task. Both capabili- 
ties are provided with the augmented syntax, shown in Figure 2.13. The scope of 
the symbol for non-preemptibHJty extends to closed control structures In the natural 
way, l.e. every task in the closed cs is non-preemptible. 

<basic cs> ::= <task> ] <baslc cs> * <task> 
<task> ::= <task ld> j <non-preemptibte tid> 
<non-preemptible tld> ::■ *<task> | *(<ev iist»<task> 
<ev 8st> ::* <event var> j <ev Mst>,<event var> 
<non-preemptibte closed cs> ::= *<closed cs> | *«ev Ust»<closed cs> 
<ctosed cs> ::= ...(same as before phis: )... \ <non-preemptible closed cs> 
Fig. 2.13. Syntax far non-preemptible tasks. 

Prefixing a task Id <or a closed cs) with an apostrophe {e.g. 'A) indicates that that 
task is not preemptible by any event. If there is an event list after the apostrophe 
(e.g. '(e1)A), then that task is not preemptible by any event In the event list. 
Furthermore, It Is not preemptible by any event which couW lead to preemption by 
an event in the event list. For example: 
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(((((A*/e 1 )«(e3)B C)/e2)D/e3)E)* 

Here if LC is at B, it is not preemptible by e3 or e2, since e2 initiates D which is 
preemptible by e3. 

Algorithm 2.2 can still be used to determine the nominal preemption structure 
for the control structure's set of basic cs's. However, the output of Algorithm 2.2 
must then be modified by removing preemptlbility relations as specified. 

2.8t Stopping the Flow of Control 

Although the emphasis has been on how LC moves within a control structure, 
these may well be times when there is simply n& work to be done for the moment. 
It is worth pointing out bow the existing notation indicates --this with some exam- 
ples. 

Basically LC will halt when it either: 

1. Reaches the "end" of a control structure, and finds no **\ or 

2. Reaches a slash (•/*) beyond which no events (which are ca- 
pable of interrupting the control structure to the left of the slash) 
have occurred. 

Several examples are given in Figure 2.14 to clarify this concept; for conciseness, 
a typical (but not unique) task string which may toa generated by each control 
structure is given. Additional notation should be self-explanatory. 
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((A*/e1 >«)* — > AAA«1BAAAe1B... 

((A/e1)B)« — > A (wait) el B A (wait) el B ... 

((AVe1)B) — > AAAelB(halt) 

«(AVe1)B)/e2)« — > A A A e1 B (wait) e2 A A A ... 

Rg. 2.14. Examples of processor Idling. 

2.0.1: Breaks in Event Coupled Lists 

In light of the interpretation given to constructs which result In stopping the 
flow of control, it will be noted that there is no way to apply Iteration to a portion 
of the control structure which includes ail of a lower priority control structure and 
part of an event coupled list. What is needed 4s the concept of a break, wMch is 
essentially a restricted "go to" statement; it directs LC to jump over the rest of 
the event coupled list to the right parenthesis matching the initial left parenthesis 
of the event coupled list. Thus it enables the iteration at the end of the event 
coupled list to be applied to any intermediate part of the list as needed. The syn- 
tax for a break Is the up-arrow (t) at the point where the break is desired; It al- 
ways follows a basic control structure, so It can be incorporated Into that BNF: 

<besic cs> ::= <task> \ <basic cs> H <task> ] <basic cs> t 

As an example, consider the control structure of Example 2.2 modified to Include 
two breaks: 

(A/(e1 t((Bt/e2)C)|e3:((DT/e4)E)))* 
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Now, when LC reaches the end of B or D, It returns to A instead of waiting for e2 
or e4, respectively. 

2.9: External Termination of a Control Structure 
Consider the control structure: 

Example 2.3. ((((A*/e1)B*)/e2)C)* 

Since B" is non-terminating, and runs at a higher priority than A*, A will never be ex- 
ecuted again once e1 occurs. 1 There Is nothing wrong with this per ae, but with 
the given notation it is not possible to. represent the case where occurrence of e2 
aborts the repetition of B, and returns control to A* after executing C rather than 
to B*. 

To do this, the notation must be able to Indicate that occurrence of an event 
terminates execution of a particular control structure, and thus LC does not return 
to that control structure until its initiating event occurs again. The modified syn- 
tax: 

<task> :-.= <task ld> | <non-preemptible tld> J <abort tid> 
<abort tld> ::= 6<task> | 8«ev list»<task> 
<abort cs> ::= 8<closed cs> | 8«ev list»<closed cs> 
<closed cs> ::= ...(same as before plus: )... | <abort cs> 

Thus It can be specified that any event aborts a task (e.g- SB) or set of tasks 



1. RecaH, that an event "flag," in this case a^ Is not turned off mW the wtd of 
the control structure which its occurrence initiates. B* has no end. 
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(e,g. 9(A B C)) or that any set of events causes termination (e.g. «(e2)B). The 
event which aborts the task(s) need not be the same as the one which causes 
preemption in a particular case; execution Is terminated as long as the aborting 
event occurs sometime after preemption and before LC returns to the task. 

If the control structure of Example 2.3 is changed to make B an <abort tid>, 
the desired behavior is obtained: 

(«(A*/e1 )8(e2)B*)/e2)C)« 

Mow the string 'A A A e1 B B B e2 C A A A ..* can be generated, where repetition 
of A and B Is for an arbitrary number of times. 

2.10: Return of Control to a Preempted Task 

There are two distinct choices of what to do when LC returns to a task which 
was interrupted during its execution: either resume execution from where it left 
off, or start over again from the beginning of the task. These two strategies will 
be referred to as resumption and restarting respectively. Each strategy has Its 
advantages and may be the best choice in different situations. A task which is in- 
terrupted often enough may never complete if it is always restarted from the begin- 
ning. On the other hand, in a process control situation the inputs to an interrupted 
task may have changed radically since It was preempted, and resuming the compu- 
tation started with the old Inputs may lead to anachronistic outputs which are not 
relevant to the current control situation. Therefore, It Is desirable to Incorporate 
means of representing both strategies Hi the notation. For complete generality, it 
must be capable of handling a situation where two different tasks In the same con- 
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trol structure may follow the two different strategies. Furthermore, It is necessary 
to remember the point of interruption in the case of resumption, so the processor 
will know where to resume execution. 

When the problem of restarting a control structure is examined carefully, it is 
seen that there are really two sub-cases which are of interest. First it must be 
recognized that the actual unit which is restarted is the task. At the next higher 
level, a task appears In a control structure as part of a basic control structure. 
Thus the problem is really how to restart a <basic cs>. If there is only one task in 
the <baslc cs>, the problem Is easily solved-simpiy restart that task. If there Is 
more than one task In the <basic cs>, then the entire <baslc cs> could be restart- 
ed from the beginning of its first task, or it could be restarted from the beginning 
of the task which was partially finished when the preemption occurred. For exam- 
ple, consider the following control structure: 

(((A B)Ve1)C D)* 

If event el occurs, and C D executes, (A B) x must be restarted (or resumed). 
Here are the possibilities: 

1 . Resume from the point of interruption, in either A or B. 

2. Restart from the beginning of A. 

3. Restart at the beginning of A if LC was at A when e1 oc- 
curred; restart at the beginning of B if LC was at B when e1 oc- 
curred. 

The first case will be the default case, and i3 assumed for all basic control struc- 
tures as they have been so far defined. The second case will be called global 
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rastartt the third case local restart If a syntax is defined for the concept of glO* 
bat restart, Jt can be used to synthesize local restart »» a special case, thus a 
syntax will be given caned "restart ca", and It mill have semantics of "global res- 
tart", the second case above. 

<restart cs> ::* > <baaic ca> 

To control the scope of the restart symbol, restart control structures are Intro- 
duced into other control structures strictly through their appearance In closed con- 
trol structures: 

<closed cs> ::= ( <basic cs> ) | ( preemptible cs> )J 

( <closed cs> <preempttoie cs> ) | ( <ctossd ca> <basic cs> ) j 
( <otosed cs »st> ) | ( <restart cs> ) 

Here is an example of a control structure containing restarts: 

((((>A BXC DX<>EX>F»)/e1)€i)* 

Execution of this control structure proceeds identically to that of the basic control 
structure (A B C D E F) until event el happens. This causes execution of Q; after 
6 completes: 

1. If LC was at A or B when el happened, LC returns to the be- 
ginning of A (global restart of (>A B)). 

2. If LC wae at C or O when e1 happened, LC resumes from the 
point of interruption in either C or 0. 

3. If LC was at E or F when e1 happened,, LC returns to the be- 
ginning of E or F respectively (note that local restart of (E F) is 
equivalent to ((>EX>F))). 
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2.10.1: Conditional Restart of a Control Structure 

There is another possibility which should be represented. In some instances, a 
task should be restarted if it was preempted by one event (or one of a set of 
events), but resumed if It was preempted by another. This is handled by explicitly 
listing the events which would cause restart of a task. Thus a restart cs without 
an event list is unconditionally restarted, while one with an event list is only res- 
tarted if an event in its event list occurred since It was last run. 

<restart cs> ::= > <basic cs> J > «ev list» <basic cs> 

Example: 

(((((>(e2)A)*/e1 )(>B))*/e2)C)« 

Here A is restarted if either 

1. A is preempted by e2 or 

2. A is preempted by e1, which starts B. B is then preempted by 
e2 before completion. 

B Is unconditionally restarted, and A is resumed if e2 does not occur between the 
time of A's preemption by e1 and the resumption of A. 



1. Note that this means that the restart causing event need not be the one which 
caused the task's preemption; there may have been a chain of preemptions which 
included the restart causing event, and this Is deemed sufficient cause for restart. 
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2.11: Codestripplng 

A time-sliced allocation of processor time can be represented with the existing 
notation by letting the event variables stand for timer-generated interrupts. One 
additional form of preemption which will be explicitly represented here is codestrip- 
plng, as outlined in Section 1.1. 

In codestripplng, calls to the operating system are inserted into a task by the 
compiler at calculated intervals, resulting in preemption of the task when they are 
executed. The syntax is as follows: 

<codestripped cs> ::* <basic cs> / <lnteger> 

preemptible cs> ::» <control structure> / <event Hst> | <codestripped ca> 

Thus codestripped control structures are Introduced into other control structures 
under the same syntax as preemptible control structures. An example of a codes- 
tripped control structure: 

((A B/6)C)« 

The meaning here is that the basic control structure A B is executed 1/6 at a time, 
based on its total (estimated) execution time; It Is then preempted and C is exe- 
cuted. When C finishes, LC returns to the point of preemption, and executes 
another 1/6 of the way through A B (whether this Is actually In A or in B depends 
of course on their relative lengths). Thus C will be executed five times for every 
single execution of A B. 

Notice that control structures such as (>A B/10) are syntactically Illegal; the 
notion of gtobaHy restarting (or tocafly restarting, for that matter) A B is incompati- 
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ble with the semantics of codestripping. Furthermore, codestripping of closed con- 
trol structures could lead to highly ambiguous or meaningless structures and is 
disallowed. This prevents such structures as ((A B/5)/10) and (((A B*/e1)C)/5). 
Structures which execute until they either finish a codestrip or are Interrupted by 
an event are allowed, as they should be, e.g. (((A B/5)/e1)C)* which executes C 
for every 1/5 of A B executed and whenever e1 happens. 
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8.1: Introduction 

This chapter presents a catalog of control structure types which the notation 
of the preceding chapter is capable of representing- It is not clamed that every 
conceivable type of representable control structure is included, but the Bst at- 
tempts to be comprehensive as to general forms. Some examples are also given of 
types of control structures which are not representable. 

3.2: Control Flow Graphs 

Control structures can be conveniently categorized by the topology of their 
Control Flow Graphs, or CFffs. A CFG is a directed graph; more precisely, it is a 
set of nodes and directed arcs, where a node represents a basic cs and an arc 
represents the movement of LC between two nodes. The nodes bear the names of 
the basic cs's which they represent. 

Consider an arc A which originates at basic cs o and has as a destination 
basic cs d. if o occurs to the left of d In the control structure, then arc A is a 
forward arc; otherwise, it is a backward or bacft arc. Either type of arc may bear 
labels: 

1. An arc which represents the uninterrupted flow of control due 
to termination of a basic cs is a forward arc, and is unlabelled. 
Note that this includes breaks as detailed hi Section 2.8,1. 

2. An arc which represents the flow of control due to preemption 
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by an event occurring is a forward arc (an event arc) and is la- 
belled with the corresponding event variable. 

3. An arc which represents the flow of control due to iteration is 
a back arc and Is labelled with an "*". 

It may seem that tasks rather than basic cs's should be at the nodes of CFG's, 
and in fact the algorithms used for determining real-time latencies must sometimes 
deal with control flow at the task level. However, this additional detail adds noth- 
ing to the breadth of representable control structure types, and in fact detracts 
from the readability of the CFG's. 1 

Figure 3.1 gives an example of the CFG for a simple control structure. 



A B e1 »C 

\ . / 



Fig. 3.1. CFG for ((A B)/e1)C)«. 
A string naming the tasks and (optionally) the events encountered in a path taken 
by LC through a CFG is called an execution of the corresponding control structure. 
A B el CAB and A e1 C A e1 C are both executions of the above cs. 



1. If, for example, a basic cs is preemptible by event e/, then every task in the 
basic cs would have a forward arc labelled el. 
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3.2.1: Priority Levels 

As an extra benefit, the CFG notation provides a convenient mechanism for for- 
realizing the concept of priority level, which has been used somewhat Intuitively 
thus far. To find the priority level of basic cs /, do the foMowlngc 

1. Let the leftmost basic os in the control structure have priority 
by definition. 

2. Find the acyclic path from the priority basic cs to basic cs / 
having the largest number of event arcs. 

3. The priority of basic cs / is equal to the number of event arcs 
in this path. 



3.3: Interrupt Driven Control Structures 

The CFCs for control structures using only sequencing and iteration are fairly 
straightforward and do not expand the catalog of representable control structures 
by much. The sequence of tasks within a basic cs is implicitly represented, and 
forward control flow from one basic cs fo another simply' translates to an unlabelled 
arc In the CFG. 

The more interesting CFG*s are those which are derived from control structures 
having event variables. It Is readily apparent that the notation has considerably 
more flexibility than that which Is needed for representing traditional priority inter- 
rupt schemes. This flexibility is derived principally through the placement of the 
""" iteration character and by use of the branching introduced by event coupled 
lists. The latter has been mentioned briefly; the former bears clarification. 

A back arc can be originated from arty basic cs by following it with an "*". 
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However, there Is a degree of freedom in specifying the (testlnatlon of the back 
arc; this will be exercised In enlarging the catalog of control structures. Funda- 
mentally, the back arc may return to the same priority level, a lower one, or the 
lowest one. If It does not return to the lowest level, a certain "shrinkage" In the 
future range of LC is experienced. This wiN be elaborated on shortly. Additional 
variations on the fundamental types are achieved through use of the Interrupt mask 
(non-preemptible tld), external abort and restart/resume capabilities. 

3.3.1: Globally Cyclic Control Structures 

Under this category is included all control structures with CFG's such that 
every back arc, regardless of Its originating priority level, goes to the first task of 
the lowest priority level. Informally, this means that upon completion of the tasks 
at a given priority level, the processor will scan all the event variables In the con- 
trol structure from the lowest level to the highest, and begin execution of the 
highest level task pending. This is as opposed to control structures with local cy- 
cles, where the lower priority events are not necessarily considered In each such 
situation. 

The traditional interrupt systems available on most processors fall into this 
category; such systems are further subdivided Into two types, which are called 
here the weak priority system and the strong priority system, m the weak priority 
system, although arbitration between Interrupts from two or more events Is provid- 
ed, there Is actually only a single tfue level of Interruption. There is a "user" or 
■main" program which runs at the lower priority, and any number of events may 
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each preempt It; however, no event may Interrupt any task which gained control it- 
self via an Interrupt. This type of control structure is represented using event 
coupled flats, as In Example 3.1. 

Example 3.1. (MMM/(a1: A|e2: B|e3: C))* 

The CFG (Figure 3.2) has an Interrupt branch from "main" for every interrupting 
event, to the basic cs it initiates. Completion of > A, B or C forces ifi lo return to 
MAIN, so there is a back arc from each of them. For the sake of keeping the CFGfs 
readable, multiple back arcs with the same destinations wM be combined, as Is 
done in Figure 3.2. It is worth keeping in mind, however, that this does not Imply 
that another type of node (Junction) has been added. 



MAIN- e2 



Xa- 




Fig. 3.2. CFG for Example 3.1. 
A strong priority system supports a ptocaase* priority; the currently running 
task has a priority * associated with It, and any events Interrupting with priority re 
> n may preempt it. With the exception of the abJWy provided for masking inter- 
rupts, the processor runs the highest priority task waiting for service at any time. 
This type of multiple priority level Interrupt system Is represented by strict nesting 
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of preemptible (and Iterative) control structures, as shown In Example 3.2. 

Example 3.2. («(A*/e1)B)Ve2)C)* 

The genera} form can be recursively constructed; each "layer" looks like: 

((iterative cs>/<event var»<basic cs»* 

which is itself an iterative cs. The <basic cs> runs at the next higher priority than 
.the rightmost basic cs in the preemptible cs>. 

A CFG for Example 3.2 is given in Figure 3.3; it can J?e seen that the proper- 
ties of nested interrupt systems have natural analogues in the graph: 

1. Let a and fi be basic cs's in the CFG. If there is an acyclic 
path from a to fi whose last arc is labelled el, then there is an 
arc from « to fi labelled el. This property stems front the transi- 
tivity of interruption In a nested, multiple priority system. 

2. There Is a back arc from the last basic cs at each priority lev- 
el to the beginning of the lowest priority basic cs. After comple- 
tion of the control structure at a given priority level, LC returns to 
the highest level with a pending request. 




Fig. 3.3. CFG for Example 3.2. 
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3.3.2: AcycUc Control Structures 

At the other end of the spectrum are found control structures with no back 
arcs; these represent completely non-iterative systems where the flow of control 
terminates when it reaches the end of any path. Such control structures are furth- 
er subdivided into two types: 

1 . Linear control structures - control .flow is straight-line and thus 
entirety predetermined, as In the example of Figure 3.4. 

2. Branched control structures - real-time decisions based on 
event occurrences determine the actual flow of control; see Fig- 
ure 3.8., wWch provides an example. 

The subject of linear control structures does not leave much room for discussion 
and is Included mainly for completeness. However, there are some Interesting ob- 
servations that can be made about branched control structures representable with 
the notation, and which apply Independently of whether there are cycles present; 
these will be considered in the following section. 



A e1 »B C »D 

Fig. 3.4. CFG for the control structure ((A/e1XB C)D). 
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«2 *C 




©4 >E 

Fig. 3.S. CFG for the control structure (A/(e1:(B/(e2:C|e3:D))|e4:E)). 

3.3.2.1: Branched Control Structures 

It Is interesting to note that while tree-shaped CFG's such as the one In Figure 
3.6 can be represented, allowing arbitrary tree-shaped Interrupt structures is not 
compatible with the transitivity of interruption. In fact, the notation cannot 
represent any tree of depth greater than one where the forward arcs are all event 
arcs. Thus a CFG such as the one in Figure 3.7 has no corresponding control struc- 
ture. 




J*\ *B 



-*C 



Fig. 3.8. A tree-shaped CFG, for (A/(e1 :B|e2:C)). 
For example, consider an attempt to derive a control structure for the CFG in 
Figure 3.7, a tree with a depth of 2. By Algorithm 2.2, It is found that since C In- 
terrupts B and B interrupts A, C must also Interrupt A. Thus an arc labelled e2 
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mist be added from A to C, and the tree structure Is lost. Event e2 (and e3) can 

be masked from Interrupting A; but then «1 is «**o masked, since it initiates B 

... ■-■-. \ 

which is ititerruptibis by e2. This seme Ine of reasoning applies to any other at- 
tempt to produce a free-shaped control struct!* e^ of depth greater than 1. 




Wg. 3.7. A CFG which has no corresponding control structure. 

Essentiafy, this restriction says that there cannot be control structures which 
have completely local preemption structures, and yet at the same time be Mtiated 
by some event. To incorporate this type of structure would require a notion of "to- 
eat" and "global" events, with suitable restrictions on their scope. The additional 
complexity this would Introduce may be Incompatible with the attempt to keep the 
notation concise, but this may be a logical extension of the language for some ap- 
pflcations. 

Although It does not represent a preemption structure, figure 3.8 shows a CFG 
which Is similar to that of Figure 3.7, but which is representable, and by the foHow- 
Ing control structure: 

f A B/te1:C )e2: D» 

The arc from A to B represents control flow on termination of A, but A cannot be In- 
terrupted. 
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,02 — ->C 

A- *f 

^•3 >D 



X. 



Fig. 3.8. A representable tree-shaped CFG. 

3.3.3: Locally Cyclic Control Structures 

Included In this class are all those control structures having back arcs which 
do not return LC to the lowest priority level task, T«s group Is further subdivided 
Into structures which never return control to the lowest priority task, and those 
which may or may not make the return at some point. While the emphasis here is 
on returning to the lowest priority level, the same sort of distinctions can be made 
about any priority level and Its superiors. Examples of each case will be given. 

3.3.3.1: Dynamically Decreasing the Range of LC 

Consider the following general form of control structure: 

Example 3.3. ( ... preemptible csXclosed cs>*/<event var> ... )* 

This has a non-terminating "<closed cs>" H construction, which corresponds to a 
back arc In the CFG from the end to the beginning of the closed cs. Although the 
rightmost "* H forces LC to return to the beginning of the control structure (If the 
"*" is reached), the preemptible cs> will not be resumed since the following 
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<dosed cs> runs at a higher priority, and Is non-terminating. 
Figure 3.9 gives the CFG for the control structure: 

txmmpto 8.4. (((A/e1)(B C)»/e2)D)* 

which has the above general form. It can be seen that once a non-terminating loop 
is entered, although it may be preempted by higher priority tasks (either momentari- 
ly or permanently), control wiH not return to any task to its left Thus Ihe control 
structure has effectively "shrunk", in that certain tasks are no longer executable, 
Thm shrinking may occur In stages, rf there are several events which Inftfste Itera- 
tive control structures, and which occur in succession; or ff may occur afl at once, 
If the rightmost such event occurs ffcs*. 




Fig. 3.8. CF6 for Example 3.4. 



3.3.3.2s External Termination of Local Cycles 

A local cycle need not always Indicate a decreasing control structure. If the 
"(abort cs>" construction is used, then control may reside for an arbitrarily long 
time hi a given sub-structure (local cycle), and Unsay return to lower priority levels 
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when the aborting event occurs. The control structure of Example 3.4 can be 
modified by the addition of a single »«" symbol; 

Example 3.5. «(A/e1)8(B C)*/e2)D)* 

Now when e2 occurs, it "shuts off" e1 as well as Initiating 0. This is a dynamic 
behavior and as such Is not well suited to representation by a CFG; however the 
real-time latency algorithms must certainly take account of it. 

3.3.3.3: Restrictions on Local Cycles 

A back arc can be formed from the end to the beginning of any closed control 
structure, and hence there is Httje restriction on its range of possible destinations. 
One notable exception occurs in the presence of event coupled lists. Figure 3.10 
gives a CFG which does not have a corresponding control structure; Its Illegality is 
the presence of a back arc which cute across the "J" syntactic boundary In an 
event coupled list. 



^ 



e1 38 

e3 



^ 



e2 >C- 

Flg» 3.10. CFG with an illegal back arc. 
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Essentially, this says that the forking caused by event coupled lists forms two 
or more independent sub-control structures, and LG cannot move freely from one to 
the other. However, It Is possible that an event external to all the branches may 
preempt any of them; thus a CFG identical to that of Figure 3.10, except that it 
has no back arc, corresponds to the legal control structure: 

(((A/(e1: B|e2: C))/e3)0) 



3.4: CFGs at the Task Level 

There are several variations on the general ctassMeatlons presented here 
which arise principally when control how at the hrter- task level Is considered. As 
previously mentioned, the complexity of the resulting CreTs limits their usefulness. 
Thus these variations are more suitably discussed In the context of latency algo- 
rithms; furthermore, they do not introduce new general classes of control structure 
types as far as the topology of their CFGs is concerned, but instead result til per^ 
turbations of those already considered. 

However, it is reasonable to examine the changes which would be induced on a 
CFG which has single tasks at its nodes, rather than basic cs's. Use of the "<hon- 
preemptible closed cs>" or "Knon-preemptible tld>" constructions results In the re- 
moval of the appropriate event arcs. In addition, if the task Immediately prior to 
the "/<event var>" construction is masked, an unlabeled forward arc is added to 
show the flow of control which occurs on termination of the masked task. 

The default mode of control return to a preempted task is resumption, as dls- 
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cussed In Chapter 2. Thus any arc (backward or forward) to a preemptible cs of 
this type must be dynamically relocated to point to the task which was In execu- 
tion when preemption occurred. Again, this Is not easily representable with a static 
CFG, and in fact corresponds to the need to store some "state" Information while a 
task Is dormant. 

If a task Is to be restarted, this problem does not arise; in fact, If an entire 
closed cs is of restart type, there will be no arcs pointing to tasks internal to the 
closed cs which originate outside of it. The only entry point from the external 
world's point of view is the beginning of the Initial task. 
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4,1t Introduction 

A primary motivation behind developing the language presented In Chapter 2 is 
to provide a representation of control structures suitable for use as an analytical 
tool. Specifically, it provides a convenient format for conveying preemption and 
control flow information to an algorithm which then determines real-time properties 
of the given control structure. 

The algorithms to be given here are not intended to provide an exhaustive 
analysis of a control structure, but rather to be representative of the types of 
analysis which may be performed. The real-time properties measured here are of 
common interest; however, It will probably be the case that, depending on the 
needs of the particular user, different real-time properties may be of special In- 
terest. In many cases, the given algorithms can be adapted for measuring different 
intervals with minimal changes. In other cases totally new algorithms may be need- 
ed, but parts of those given will stM be useful. 

Much of the terminology used here was developed in [Telxeira 73] and the 
reader is referred there for a complete discussion. 

A principal goal here will be to develop algorithms for determining the worst 
case latency of a list of tasks in a given control structure. Informally, the worst 
case latency of a list of tasks « (written tie)) is the longest time that can elapse 
without there being a complete execution of each task in the list in the order 
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given. The list of tasks whose latency is being measured will be referred to as a 
constraint. The latency of a constraint is measured with respect to an execution 
of a given control structure, where an execution is a list of tasks in the order in 
which they are executed by the CPU in a particular invocation of that control 
structure. Each element (task id) of the execution has a weight associated with 
It, written as |<task id>|. The weight represents an upper bound on that task's 
execution time on a particular processor. 

Note that depending on event timings, a number of different executions (of 
finite or infinite length) may be generated by a single control structure. Consider 
the control structure: 

(((AB)«/e1)C)« (5.1) 

Possible executions include: 

A B A B A B ... 
A B C A B C ... 
ABABCABABC... 

among many others. Also note that in the case of preemption a task may be 
suspended and restarted, and thus partial weighting (or Its effective equivalent) 
must be accounted for. 

The weight of a list of tasks is the sum of their individual weights. The worst 
case latency of a constraint a with respect to an execution 0, is the sublist of fi 
with greatest weight which does not contain a. The term "contains" as used here 
means that the elements of « occur in order and with their full weights; there may 
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be arbitrarily many other tasks interleaved. For example, (A B C D) contains (A O 
as wen as (A 8), but ft does not contain (C B). 

The provision that the tasks be Included with their fun weights is emphasized 
for the following reason. In many real-time process control applications, the inputs 
to a task may change at any time, but the scheduling of task Initiation may not be 
synchronized with the arrival of new Inputs. Thus It is entirely possible that new 
inputs may arrive immediately after the Initiation of a task, i.e., after It has already 
read the outdated inputs. Given this posslWSty, It may be that nearly two complete 
occurrences of the constraint may be executed In an Interval which still does not 
contain (In the strict sense denned above) a single occurrence of the list For ex- 
ample, given the control structure (A B C)", consider the execution A B C A B C. if 
an Input to A arrives immediately after A reads its old input? then it is only after 
the second occurrence of C has completed its execution that all the tasks in the 
constraint will have been executed in order (the constraint is satisfied by such an 
execution). Thus a way is needed to represent an execution whose end-tasks are 
weighted Just less than their nominal values; the notation chosen is bracketing 
such a task on its "short side"; [A means "begin just after the start of A", and C] 
means "stop Just before the finish of C". The weight of such a task is Its nominal 
weight minus «, where • fs arbitrarily small. Thus the worst case latency of (A C) in 
(A B C)« is | [A B C A B C] |. 

The Bst (A B C A B C) is en example of a. critical window for (A C), where a 



1. Unless it is known that the timings of such data arrivals can be synchronized 
with task Initiation, It must be assumed that thtet could occur at any time after A is 
initiated. 
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critical window Is defined as a list « such that * contains two occurrences of a 
constraint C but [«} contains no occurrences of, C. In many cases the worst case 
latency of a constraint will turn out to be the weight of a critical window (the /nest 
critical window). The worst case latency of a constraint with respect to a control 
structure (as opposed to an execution) is taken over ail the possible executions 
that may be generated by the control structure - : no matter whet the event timings 
(within specified limits), there can be no longer interval which does not contain the 
list. Thus part of the problem faced is to classify the types of executions which, 
may be generated by a control structure and. narrow the a Gholce among them for 
finding the worst case, since otherwise the. combinational explosion in the number 
of possible executions would make the problem Intractable. 

4.2i Weight* of Task Identifiers 

It was mentioned briefly above that a weight is associated witti every task 
identifier, representing an upper bound on its execution time. Naturally this must 
be with respect to a particular, processor, but even wjth.thls restriction there are 
some difficulties in determining a meaningful upper bound on execution time. Aside 
from input dependent computation times, there are processor dependent variables 
such as memory access time In a virtual storage system. The worst case time 
would occur when all memory references were to the slowest storage device, but 
the probability of such a case actually occurring may be nearly zero. On the other 
hand, there may be an uncomfortably large variance associated with the mean ac- 
cess time when critically time-dependent processes are involved. It seems then 
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that in such a case one must either arrive at a statistically reasonable upper bound 
on memory access time or change the storage allocation parameters of time depen- 
dent teaks to ensure their residence at a particular level or above (In access 
speed) of the storage hierarchy. 

If an upper bound on the execution time for a task does not exist, this would 
imply potentially infinfte worst case latencies and there would be no purpose to ap- 
plying the algorithms given here. If there is any question of the value of an upper 
bound, then It most be chosen carefuBy In light of the particular application of the 
latency information. The weight of each task WW be an Input to the latency algo- 
rithms along with the control structure, and it w» be assumed that a function (table 
look-up) exists which returns this weight ki response to the notation f<task id>{. 

4.3: Properties of Event Variables 

In order to arrive at worst case latency times for a control structure containing 
event variables Mr "Is necessary to know something more about the timing of the 
events represented. To illustrate, consider the control structure: 

(((A B)Ve1)C Dy (&2) 

If ef never occurs, the only possible execution of this control structure is (A B A B 
A B .„). The latency KA B) in this case is 2(|A|+(B|) - <, since the longest subKst 
which does not contain A B would be [ABA Bj. On the other hand, if el occurs at 
least once every fCf+iDf seconds, then KA B) is trrflntte, smce the only execution 
generated Is (C D C D C D ...) (ignoring possible Irritlal executions of A and B). If 
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the control structure contains more event variables it may become difficult to deter- 
mine the worst case latency (the largest l(A B)) by inspection, and the need for 
additional information about the event variables is clear. 
In particular, what is needed is the following: 

1. 'my^Ce.-): the minimum period of event e.; it is guaranteed 
that e, will not occur more than once in any interval of * m jff&j} 
seconds. 

2. »_,„(e.): the maximum period of event e,; it is guaranteed 
that there will be at least one occurrence of e, in any interval of 

w max^ e P seconds - 
It is entirely plausible and indeed likely that In some situations * m / n i e j) wi " De 
the same as »_ M1 ,(e,). This is the case for all regularly occurring cyclic events, 

such as data sampling, processor time slicing, etc. 

In general, it is impossible to distinguish a "■ • (e.) which is less than the pro- 
cessor instruction cycle time from an infinitesimal one since the processor could not 
possibly respond to an event which occurred at that rate in any meaningful way. 
In fact, for a reasonable system, one would have to pick a * m j n (©/ ) considerably 

larger than the Instruction cycle time, but the actual value will be application 
dependent. For most events of interest it will be possible to determine a reason- 
ably tight »-,/»(«/); e -9-> 'f tne event represents an I/O service request, it cannot 

occur more often than some time interval dependent on the I/O device's maximum 
character transmission rate. 

Unfortunately, finding a good value for *_„,,(e.) is more difficult in many cases. 
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An event often represents an exceptional condition, which may never arise in par- 
ticular executions. Fortunately, most control structures wffl not put time critical 
tasks in such a position that their Initiation depends on * /WUf (e / ), but rather It is 

more Nkeiy that the completion of a constraint may be influenced by time tost after 
such an event occurs; and the time tost will be * function of »—j n tep» not 

'fl^yjCS/). If a good value of 9 maK (.B j ) is not available for a particular event, then 

It is more ffksfy that the Interval of interest wootd be the maxfmum time from the 
occurrence of e> to the initiation and/or completion of its associated control struc- 
ture, rather than the longest time between such executions (a latency value). 
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6.1: Introduction 

A series of hierarchically related algorithms will be presented in this chapter, 
which will be directed at the problem of finding the worst case latency of a con- 
straint with respect to a given control structure. Each algorithm in the hierarchy is 
applicable to a larger subset of the set of all representable control structures, and 
may call upon the algorithms designed for solution of the problem on a lesser sub- 
set as subroutines. 

The overhead due to context switching is not explicitly taken into considera- 
tion here. It may be accounted for by a fractional reduction of the effective pro- 
cessing power of the CPU, when computing the worst case task weights. If this is 
not satisfactory, then the algorithms could be adjusted so that each event oc- 
currence and corresponding initiation Is counted, and the overhead due to each 
could be added to the delays attributed to interruption. 

As the worst case latency algorithms are developed, it will be seen that the 
determination of algorithms to measure several other real-time properties, Interest- 
ing in their own right, is required. Finally, special cases may result in substantial 
simplification to the algorithms, and examples of this effect are included. 
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5.2: Latencies In the Absence of Preemption 

The first step taken here toward the general solution of the worst case laten- 
cy problem Is the development of algorithms to determine the latencies when no 
preemption Is present, i.e. when there are no event variables or cpdastcjps In the 
control structure. This leaves control structures which generate finite and infinite 
lists of tasks, in which all tasks execute to completion once initiated. 

Since only non-terminating Iteration is represented (In the absence of preemp- 
tion), all finite lists must contain no Iterative components. Furthermore, any finite 
list L of tasks which contains at least one occurrence of a constraint d may be 
broken down into a series of possibly overlapping subUsts: 

with respect to a constraint C where: 

1. * 1 and $2. • acn contain one Instance of C, but 0^] and \fi z 
contain no instances of C. 

2. The ^'s are critical windows for C. 

The subllst 0^ » the head of the Ret L having minimum weight and which also 
contains one instance of C; £ Is the tail with least weight which contains one in- 
stance of C. The list « t is the critical window which starts at the flret instance In 
L of the first task in C; a f » the critical window which starts at the Ith instance 
In L of the first task in C. If L contains no critical window, there wM be no «,'s; 



1. If L does not contain C, then the latency of C in L is infinite. 
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similarly, if L begins or ends wltb a critical window then /Ij or * 2 respectively may 
also be empty. 

Figure S.1 gives an example of the breakdown for the list (ABCDBCBCE) 
and the constraint (B C). Note the overlapping of the sublists, and that in this 
case l^l* le^l. 
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Fig. 5,1. Breakdown of a finite task list Into sublists. 

Theorem 5.1. The latency of a constraint C with respect to a Unite list L which 
contains at least one occurrence of C Is the majdmum weighted auWlei in 
the set of subjst* {fi v * v • • ■_. M^f^h where .the e^and *,*» are as 

defined above. l 

Proof. The proof will be given in two parts; first* by showing that any llsj which 
contains at least one occurrence of C can down in the above manner to 

obtain such a set of sublists which Includes ail the tasks in the original Hat; and 
second, by showing that no othsr subttst not m the set can have a greater latency 
for C. :..,.,,.. 

The proof of the first part is given by showing a method of constructing the 
set {fi v « 1( « 2 , • ■ ■ ,*„, Ig} given such a list L and a oortstEatet C* 

Find each sublist of L which exactly contains one instance of C (i.e., a sublist 
1 such that y contains C but fcr and ?ldo nqt contain Ck JabJtl each, such sublist 
r r for / * 1 to n, where n Is the nu instances c# C in L. The list L can 

thereby be considered as a series of sublists; 

+V "V *2' y 2> "■'• +n-V T/i-V *n < 62) 
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where the ♦/•do not contain C and may be empty, if y. overlaps 7i +1 . then $, +1 

will be empty. This set of subliats includes every task in L, and with no permuta- 
tion of the original ordering. Then: 

1. #- is 4i appended to t^. 

2. «. is the list starting at y. and continuing to the end of Ti +1 . 
Including ♦/+■§• Mote that since y, and t/ + i raay overlap, *. is 
/lot their concatenation. 

3. * 2 te *n-i «M>Ponded to * . 



Now for the proof that the worst case latency of C in L Is the maximum of 

Since the «^s are all the critical windows in L, they represent all the lists « 

such that [«] cannot be expanded in eJttier <#rectfc^ without the Resulting interval 
containing C. Similarly, 0fitu\d (^ 2 cannot be expanded oh their bracketed sides 

without introducing C to the interval. Since the concatenation of 
OLp « 1 , « 2 , - ■ • .ft^, # 2 ) contains |. r and norm of these sabttst* can be E xpande d 

without the reauMng subftst containing C, ihdW^^tUS^ftAr 0»e jf^fetence of a 
sublist with greater latahcy w «urti#»e*tf is 8uefr*a «lt wbf§H Trfcilu^" parts of two 
of the above subHsts. That such a subllst with greater lataacy does net exist is 
demonstrated by case analysis. 

Again, consider the fist L reorganized as In equation (6.2). Now, suppose that 
there exists a submit f which Includes part of J0L and *y and that |#] > 

|0 t J and ^| > J^l- The subHet # cannot begin, torpor it>oouid not contain any- 
thing past 7 1 (without containing C) and hence \+\ < |£,|. But if it starts at the 
beginning of 7^ It could Include no morethan a v and therefore j*| 5 |«^ If-* be- 
gins past the beginning of ?i> It cannot contain anyttrnig/ past ?£, an# hence |#f < 
|« 1 1. Thus such a sublist # does not exist. 

The same line of reasoning wfll show tJwt a sub^t wWv greater weight than 
any of {#,, « 1 , • ■ ,«_, #1} cannot being constructed from parts of adjacent «/s, 

or « and 2 - Tnus the worst case latency of C in L wW be the maximum of (|0..|, 
Algorithm 5.1, FLATENCY, summarizes the procedure to be followed in finding the 
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worst case latency of a constraint C with respect to a Unite list L. 
Algorithm 5.1. FLATENCY(L, C) .-->■» 

Inputs: L, a »st of task Identifiers (a basic control structure); tJ/J ts the /th task 
i»L. 

C, the constraint (also a list of task Identifiers); C[fJ Is the /th task in C. 

Outputs: (1(C), start-index, finJshJndex); 

1(C) is the worst case latency of C in L. 

startjndex is the index of the first task of the sublist of L which displays 
the worst latency for C. 

flnishjndex Is the Index of the last task of the sublist of L which displays 
the worst latency for C. 

Method: 

1 . Scan L to And: 

ff 1 , the head of L with least weight which contains C. 

«y, / = 1 to n where n Is the number of occurrences of C In L 
minus 1. 

2 » the tail of L with least weight which contains C. 

This is accomplished as follows. All scans start from the mark point, initial- 
ly L[1]. 

a. Reset the mark point to be the first occurrence of C[1] found 
ourlng ea«h scan, w iwftwautten^ 

point is set to the task past the end of the current scan. 

b. 0j is found by scanning untH a complete occurrence of C has 
been found; 

c. The mfs are the lists which exactly contain two occurrences 

of C; they .a/#- found b# scanning from Mer mark point for one oc- 
currence of C, and then scanning from the new mark point for the 
second occurrence of C. 

d. 2 is tee result of the flnai soan If no tali of L Is a critical wln- 
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dot*. 

e. If no occurrence of C is found in i, return <<», -1, -1). 

2. The weights of each subHst are accemutafced during each scan, as well 
as the startjndex and flnlshjndex for that scan. At the end of each 
scan the weight is compared to the largest found so far, and saved as the 
new maximum KC& ,# i| is ^greater (to wWcfti ease stertjadex and 
flnlshjndex are updated to the values for the Just scanned list). 

3. Return the final values (MAXIMUM^ |, kjl, •■•, |a fl J, |* 2 |), 
start-index, finishjndex). rt 

6.3: Latencies of Constraints in Cyclic Control Structures 

In the specified language an infinite list of tasks Is generated by the iteration 
construct; iteration is either applied to an entire control structure or to the last 
closed control structure in a <closed cs Hst>. Thus infinite lists are either entirely 
cyclic (the entire structure Is repeated): 

(A B C D E)« (6.3) 

or have a start-up period followed by a steady state cycling: 

(A B CXD E)* (5.4) 

It would be indeed unfortunate if the entire Infinite list had to be examined to find 
the worst case latency, but due to the restrictions on Hs cyclic nature only a rea- 
sonably small number of cycles (to be determined) have to be examined to find the 
worst case. Thus the intention here is to reduce the case of an infinite list to a 
finite ttst which contains the worst case, and use Algorithm 6.1, FLATENCY, on the 
result. 

The principle question is thus to determine how many cycles of the iterative 
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portion of the list need be appended to the non-iterative portion (if there is one) in 

order to generate a list containing the worst case latency of a specified constraint. 

First, though, It must be determined whether or not the latency is infinite (assuming 

no task id has infinite weight). 

Lemma 5.1. Given a control structure foXf)* and a constraint C, the worst case 
latency of C in (^)(f )" is infinite iff C contains a task A which is not con- 
tained In f. 

Proof. If i does not contain a task A which is in C, then (f)* is an infinitely long 
list (and hence of infinite weight) which does not contain C, and thus in which C 
has Infinite latency. 

If f does contain every task in C, then if C contains n tasks at least every n 
repetitions of i contains C and hence the latency of C in (+)(#)* could not be 
Infinite, n 

Once it has been established that the latency is not infinite, the following theorem 
can be applied to find the subllst which contains the sublist with the worst case la- 
tency. 



Theorem 5.2. Given an iterative control structure L = («>)(f )* and a constraint C 
containing n task identifiers, then if the latency of C in L is not infinite, 
the list formed by appending n + 1 copies of f to i contains the sublist 
with the worst case latency for C in L. 

Proof. Theorem 5.1 established that the worst case latency of a constraint in a 
list of tasks was either a critical window or. or a head or tail of the list 0.. or 0„. 

By Lemma 5.1, if the latency is not infinite then f contains every task in C. There- 
fore 

0-, £ ♦, + n (5.5) 

where i> n means n copies of 4> appended to each other. This is true since n copies 
of f must contain C, since each 1> contains each task identifier in C. Note that ft* 

might be wholly contained in ft, nonetheless. 
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By similar reasoning^ 

contains the most critical Wfrxtow of (#)(#)"; If -the- "most critical window is con- 
tained in ♦, then equation (6.6) must contain it. Otherwise, it is contained in 
(+X*)". If the most critical window starts in ♦ but ends^ifW*, ; "ftien ft cannot go 

any further than j> n since the first a copies of ^mt^t. contain C; thus equation 
(6.6) contains the most critical window If this is the case also. 

Finally, suppose that (#)" contains the most critical window. Consider the list # 
formed by starting at the first occurrence of Cf^jn^tr}*, first copy of #, and ending 
at the last occurrence of C[n] In the n + 1st copy of #.. the list I must contain 
two occurrences of C, since # 1 through + n contain C, and ^ 2 through ^ +1 omXtkh^ 

C. If [#] contains no occurrences of C, then # Is a critical window. If I is a critical 
window, then no critical window can exist which Is Jaeger than 9 since It would have 
to be constructed out of more than n ♦ 1 copies ' of tfCand^iitts would contain #. 
Thus if # is a critical window, it is the most critical window in (#)*. But if f is net a 
critical window, then it must contain a critical window, and by the same logic this 
critical window must be the most critical window in (#)*. o 

Algorithm 6.2, ILATENCY, shows how to use Theorem 6.2 coupled with the algo- 
rithm FLATENCY to determine the worst case latency of a constraint with respect 
to any control structure which does not contain preemption. 
Algorithm 6.2. ILATENCY(L, C) 
Inputs: I, a control structure which does not contain preemption. > 

C, a constraint (list of task identifiers). 
Outputs: (KC), start_lndex, nu«_tasks) 

KC), the worst case latency of C in L. 

atart_lndex, the index in L of the first task of the list whose weight is 
KC). ;■* 

num_task8, the number of tasks in the list whose weight is KC). 

Method: ■■.-.-■ v>-<-- 

1 . If L Is not Iterative, let (KC), atartjndax, finish Jndex) » FtATENCYft, 
C); return(KC), start_lndex, finish_index - start-index + 1 ). 
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2. If L is iterative, then divide L into its iterative and non-iterative (if 
any) parts: L = (♦)(#)*. 

a. If f does not contain every task in C (not necessarily in ord- 
er), return(«>, -1, -1). 

b. Let K. * ♦, ^ n+ ' where n is the number of tasks in C. Let 
(1(C), startjndex, finishjndex) = FLATENCYflC, C); return(l(C), 
start-index, finishjndex - startjndex + 1 ). 



6.4: Latencies of Constraints in Preemptible Control Structures 

The next complication to be dealt with is the presence of event variables and 
multiple priority levels, implying the possibility of preemption before completion of a 
constraint, and thus additional weight for the worst case latency. In fact, at this 
point the possibility of infinite latencies arises due to lockout by higher priority 
tasks, even though the constraint may be contained in an iterative portion of the 
control structure. 

The general case of preemptible control structures contains many additional 
complexities, if one includes external termination of control structures, non- 
preemptible tasks, codestripping, restarting, and idle time due to stopping the flow 
of control. Thus, in keeping with the theme of building a hierarchy of algorithms 
which handle increasing complexity with each new layer, the applicability of the 
next algorithm is restricted to include all the control structures allowable as inputs 
to ILATENCY, plus those containing <event list>'s «event var>'s and <event cou- 
pled list>'s). Specifically there are the following restrictions: 

1. No external termination (<abort tid> or <abort cs>). 

2. No restarting of control structures (<restart cs>). 
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3. No codestrtpptng «codestripped cs». 

4. No non-preemptible tasks «non-preemptlbie tid> or <non- 
preemptible dosed cs>). 

6. No stopping of LC. The highest priority ready task must al- 
ways be initiated without delay. Thus a control structure such 
as: 

((«AVa1)B)/e2)C)* (6.7) 

is illegal but 

((((A*/e1)B)*/e2)C)* (6.8) 

is not. Event coupled Rsts must contain breaks (cf. Section 
2.8,1) to ensure that waiting for higher priority events In the 
event coupled list does not occur. 

6. Constraints must be contained wholly in a subcontrot structure, 
defined as a **ries of basic cs's, an Iterative cs, or closed cs 
Rats at a single priority level. In CFG terms, a subcontrol struc- 
ture Is an. acyclic path through the «mteol,stn«Bture!s CFQ which 
contains no event arcs, back arcs or breaks. This allows ail pro- 
cessor time spent at any other level to be treated as an addition 
to worst case latency, and lets the details of exactly which 
tasks are contributing to the increase be ignorsd- <Additkxialry, 
the tasks of the constraint must not be contained in more than 
one subcontrpj struqture. If they are, then the worst case* laten- 
cy in the entire control structure would be £ the minimum of the 
worst case latencies in each subcf^pl stf uctu^^ 

the constraint; thus the present algorithms stW give an upper 
bound. The problem here is that if the cof^straint carvbe satisfied 
by an execution which spans two or more priority levels, then the 
tasks being executed during preemptkxv swat be iderttifled, and 
can no longer be lumped together and treated as time lost to in- 
terrupts. 

7. Infinite event queues. An infinite number (or some suitably 
high number representing the maximum possible number of pending 
events) of occurrences of each event , are remembered. This 
means that if an event happens before the previous occurrence 
has been cleared (by completion of the initiated control struc- 
ture), the new occurrence wflf be held in a o^raiue and not Ignored. 
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6.4.1: Definitions and General Approach 

The addition of preemption to a control structure Introduces several Interesting 
timing questions, for example: 

1. The worst case latency of a constraint as previously defined, 
I.e. the longest time that can pass without their being a complete 
execution of each task m trie constraint hi order. This may now 
be prolonged by Initiation delay as well jas^pjeeBjption delay. Ini- 
tfatton delay is time lost' <tuB to the initiating event not yet having 
occurred. 

2. The worst case latency of an event,, defined as the longest 
time that can elapse between the occurrence of an event and 
the start of the subcontroi structure which it initiates. What ex- 
actly constitutes the initiation of a subcontroi structure wlH be Im- 
plementation dependent. 

3. Related to (2), it may be desired to know the worst case exe- 
cution time of a Hat of tasks at m given priority level; this Is tiielr 
execution time in the absence of preemption plus the most possi- 
ble time tas* to preemption. This may be mor* useful than ff y in 
cases where occurrence of an event signals the arrival of new 
data, rather than assuming that task InWatton Is onsynchronlzed 
with data arrival times. 

In all these esses it wilt be necessary to make some assumptions which could 
lead to an upper bound whteh Is somewhat greater than the actual worst case (In 
addition to the uncertainty in the estimate of worst case task execution time). In 
particular, Teixeira has shown [Teixeira 78] that; the worst case occurs when all 
interrupting events happen at the beginning of an interval and continue happening 
at their maximum rate. It may be that the phase relationships of the events cou- 
pled with the execution times of their subcontroi structures is such that the 
events could never an happen together; if this is known in a particular case then 
its worst ease may be different, and the Initial phases of the events could be ad- 
justed accordingly. The algorithms do allow specification of event phases, as will 
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be seen. In any case the algorithms do give an upper bound to the problem. 

The worst case latency of a constraint which executes at priority (the 
lowest priority) can be determined in terms of nominal time in the absence of 
preemption plus time lost to Interrupts; the Initiation delay need not be considered. 
The fundamental difference between tasks at priority 6 WM* priorities greater than 
is that if the Worst case latency of a constraint involves more than one execu- 
tion of tasks at a priority level greater than 0, there may be delay due to initiation 
of that priority level (which must be figured according to n mak of the initiating 

event in the worst case) for the additional task executions. The lowest priority 
level is assumed to be always running or ready, and thus has no such delay. 

In general there wiB be some thought required to pinpoint the worst case for 
any time Interval of interest; once determined, =. that algorithm to measure such a 
time interval can be constructed using the following baste technique. 

1. Determine Ihe relative priorities of every basic cs in the 

overall control structure, and associate *rt tt> each event variable 

the subcontrol structure which it initiates (cf. Section 2.6.6). The 

priority of a subcontrol structure: end tts ieftiafing event are the 

same. It is assumed that »_,.. and «■_„ are known for each 

tnin max 

event (ciVSeetfon^.a). 

2. Determine whether the time Interval (latency or otherwise) is 
Infinite. This may be done in two steps: 

a. If the time interval is infinite in the absence of 
preemption (determined as previously shown), then it is 
Infinite In the presence of preemption. 

b. Otherwise, find out whether higher priority tasks can 
sufficiently toad down the processor so that tt» interval 
of interest Is never completed. One method for doing 
this WIH be shown. 

3. If ft Is not Infinite, determine the Interval m the absence of 
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preemption and ether delays. 



4. Factor in the loss of time due to preeaptJon and other delays; 
lifting any of the restrictions given in Section 6.4 will usually be 
seen as perturbations of this factor. 



6.4.2: Finding Infinite latencies 

The control structures represented here provide no a gfjorl method of guaran- 
teeing fairness If preemption is present; Le., ft la entirely possible that in the 
worst case some tasks in the control structure may nover be executed due to 
preemption by higher priority tasks. " « A 

Fortunately It is possible to determine whether this Is the ease #i advance and 
at low computational cost, and this must be done before continuing with the 
analysis. If the latency at a given priority level Is Infinite then the iterative solu- 
tions to be used for solving for loss of time due to preemption do not converge. 
The method used is to deternMne a toad factor for each aubcontrol structure that 
can preempt a given one, and if the load is £ 1 then the given control structure's 
tasks wlH never execute. 

In order to find the toad factor due to a suhcontrol structure i with initiating 
event e^, it is necessary to partition the set of events In the overaj| control struc- 
ture as follows: 

1 • Eg/ways : the ••* of events which can always preempt #, but 
can never be preempted by e^. These are the events of higher 
absolute priority than a., as found by Algorithm 2!SL 

2. E^ tt0 ; This Is the set of events which cannot preempt f 
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and cannot be preempted by e ., but «§• «ho*enr*wer «w if e. 

and one of them are both pending at the same time. This set is 
the union of the foitowfctg setsr " 

a. Events which have the same absolute priority as e . , 
but occur to its left in the same event coupled Hst. 

b. Events which have the same absolute priority as e ., 

but occur in a different event coupled Mst^whicb is entire- 
ly to the left of the event coupled Hat containing f . 

c. Events which have higher absolute priority than e . 
but occur in an mvent coupled Hst which does not contain 

3 * E /ose tie ' Tn ' 8 te the set °* ovent8 WbJch cannot preempt # 
and cannot be preempted by e^, but e . is chosen over one of 

them rf both are pending at the same trnie. This Sot of events is 
the union of the following sets: 

a. Events which have the same absolute priority as e - , 
but occur to its right in the same event coupled list. 

b. Events which have the same absolute priority as e ., 

but are in a different event coupled »%t which is entirely 
to the right of the event coupled list containing f. 

c. Events which have a lower absolute priority than e ., 

but occur in an event coupled list which does not contain 
e.. 



4. E neyer i TMs is the set of events which can never preempt 



e., and initiate subcontrol structures which can always be 
preempted by e . . These are the events of lower absolute priori- 
ty than e^. 

As an example, consider the control structure: 

(A/<e1:B/(e2:C|e3:D)|e4:E/(e5:f|ee.-G)))* (5.0) 
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Its preemption structure appears In Figure && and the partitioning of Its events in 
Figure 5.3. 




Fig. 6.2. Preemption structure for (6.0). 



Initiating Event 
/Task 
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never 


none/A 
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e3/D 


none 


e2 


e4, e6, e8 


el 


e4/E 


e5, e6 


e1, e2, e3 


none 


none 


e6/F 


none 


e2, e3 


e1, e6 


e4 


efl/Q 


none v, 


•ma^m, «6 


e1 '■ 


e4 



Fig. 6.3. Partitioning the events of (6.9). 

To decide whether a task A at a given priority level In a control structure may 
never execute, partition the events of the control structure relative to A as Just 
described. Each event initiates a subcontrol structure (at a single priority level); 
let e f initiate subcontrol structure + r The worst case load of a given subcontrol 
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structure on the processor occurs when Its Initiating event happens at its maximum 
frequency: 



IM 

Worst case toacK*,) - - — -(ej (6.10) 



The total load factor is the sum of the worst case load factor for each event which 
might participate in the btockout of A; this is the set E-^^^ = 

^always u E w/o t/e^' since those are exactly those events which consistently get 

control over e A no matter how long e. may have been waiting in queue. Of course, 

If A is In the lowest priority control structure, there Is no e A and the set ^ wfn ti0 

is empty; but the analysis of possible blockout due to preemption is unchanged. 
Let the events in E^ ooro ^ 3 be {ay, ■ • • ,e,}; then the total load factor is: 



Total load factor(A) » k p — LJL. (6.11) 



If the total load factor is * 1.0, then the task A (and any other task in the same 
basic cs as A) never gets executed; its worst case latency is infinite. AH the fol- 
lowing algorithms assume that this check has been made before they are called, so 
that a finite solution is known to exist. 
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5.4.3: Delay Due to Preemption 

The problem of determining the time taken up by preemption lends itself natur- 
ally to an iterative solution. In the worst case It must be assumed that every in- 
terrupting event happens at Its maximum frequency (once every r . seconds). 

As the tasks Initiated by one interruption are being executed, there may be addi- 
tional event occurrences, causJno further deJay, etc. By aquation (6.1 1), If the 
load factor is < 1 It is guaranteed that at some point the task in question (the one 
being preempted) will execute; but it is not clear when and for how long before it 
is preempted again. 

The problem Is then to solve for the %etai time taken to execute some set of 
tasks f> of total weight W^, in the presence of a set of interrupting events 

{e /t ■ ■ • , Oj} which all happen at time zero and then again every f mfo (9, ) 
seconds, each initiating subcontrol structures with weights {W., ■ • - , W .}. The 
total time, r,, is: 



T,-W.+ k 2 J 
A-/ 



*mift*k) 



W. 



(6.12) 



The ceiling function is chosen since the iquotient 



<WV 



(6.18) 



gives the number of occurrences for e A in the interval {T.; but since aft events 
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happen at the beginning of the interval (in the worst ease) one additional oc- 
currence must be added 



1 + 



WV 



(6.14) 



but if the event occurs at the exact end of the interval 7v this occurrence must 
not be counted since ? wW alraady be completed - thus the choice of 



W e A> 



(6.16) 



A quick iterative solution to (5.1 2) Is had by noticing that an excellent lower bound 
is the solution to 



T+W. 



r '**V>wWV 



<6.16) 



which is 



Wj 



V" 



t-*i J 



-i ** 



(6.17) 



k-l w miiS*k) 



Notice that the denominator is exactly 1 - Equation (6.11), the total load factor, 
which has already been computed. Equation 6.17 impRes that running t with inter- 
rupts is Wee running # on a processor whose str eng th has been dtmtotahed by the 
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load factor of the interrupting tasks. 

Thus equation (5.12) is solved Iteratfvefy by letting 



W, 



'° ,M "* 



1-Z 



A-* 9 mltfak) 



(6.18) 



and then solving for T . 



W " W A-/ 



r /i-1 



WV 



^ 



(6.19) 



and stopping when f. -7. . The right-hand sMe ta 

v n r «-1 



Ulry Increasing 



with r^ and this process converges very rapidly since the Initial guess is so near 

the final value. 

Given a computation whieh takes a known timet in the absence of interruption, 
Algorithm 5.3, PTIME, computes the total time taken to do the computation In the 
presence of interrupts. It He assumed that them is no Initiation delay Involved, i.e. 
PTIME finds the worst case Interval which contains t seconds of time in which 
preempting tasks are not executing. 



Algorithm 5.3. PTIME(t, ^ pmam S ) 

Inputs: 1; a time which represents computation time in the absence of preemption. 

^preempts' a * 9 * of events which can preempt the computation which 
takes t seconds. 
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Output: t , the time taken In the worst case wttfc (nterrupts to perform a computa- 
tion which takes t seconds without mtefrgpts (i.e^. PTtME assue»9 an the 
events In E nn| ^^ happen as soon as the computation starts, and con- 
tinue at thea* mexmuim rate) 



method: 



1. Let Wj « t. Let {«^i •;, ' . «j> be the events In E^^. Let 

{Wj. • • • > W.} be the weights of the subcontrol structures initiated by 

the corresponding events. Then solve equation (6.18) lor an initial value 
of r.; solve equation (6.19) repeatedly for r. usta the Value of f. "," 

w 9 n r »-1 

ending when T. « T. . Return(r . ). 
r i» *o-1 *» 



6.4.4: Applications of PTHBE 

Using the algorithm PTttlE one can determine several realtime properties of te- 
terest for control structures which meet the restrictions of Section 6.4. it must be 
kept in mind that there » a distinction between the fosbwing two sets of events: 

a. The set of events which csn preempt a task after It has been 
initiated, as was as take priority ever It* tnitiatihg event white ft 
is pending. 

b. The set of events which get priority over an event if it » 
pending bet has not yet been recognized by til* processor (no 
tasks have been initiated due to its occurrence), but cannot 
preempt any tasks to the subcontrol structure which that event 
initiates. 

The worst case latency of any constraint which is in the subcontrol structure 
at priority can also be directly determined. The dteti r mtiu ii between thte applica- 
tion and the one just mentioned hi that Me constraint need not be contained in a 
single copy of the subcontrol structure. Smce the priority subcontrol structure 
has no initiating event and hence no initiation delay, the worst case latency of a 
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constraint C can be determined In two steps: 

Algorithm 5.4. PRIOLATENCY(#, C) 

Inputs: 1>, a subcontrol structure which runs at priority 0. 

C, a constraint. 
Output: 1(C), the worst case latency of C in f. 

Method: 

1. Find (1(C), sljartJndex, num_tasik«) = JLAJE||CY(#,,C) f the worst case la- 
tency of Cm the absence of preemption. 

2. Let "fm-QQ^jKa toA *• **%■** mirtoMHm m the entire control structure. 
The worst case latency of C is PTIME(KC), E^m— (.)• 

Another application is to determine the latency of an event a,, that is, how 

long is it in the worst case between the occurrence of an event and the initiation 
of the corresponding subcontrol structure. This can be found as follows: 

Algorithm 6.5. ELATENCYfc, e,) 

Inputs: •, the least amount of time that can elapse before a task can be con- 
sidered initiated. ,\..-, iV 

e,, the event whose latency is bemg determined. 

Output: t_ , the longest time that can elapse after e> occurs before its subcontrol 

' .,- ... . 

structure gets Initiated. ' ' ! 

Method: 



1. Let the s* 1^^ m <i^^«4 |W/M|e> re,atlve to 



2. y » PTIME(., E ArB0fB ^j: 



-*t»* 
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6.4.6: Adding Phase Relationships to PTttdE 

For a more general formulation, it is useful to have available the means of 
determining execution time in the presence of interruptions when the interrupting 
events may have started happening at any Individually determined time rather than 
an starting at time zero. For this pu/pose, the phase at an event is here defined as 
the time since Its last occurrence. Thus for a set of events {e,, ■ • • , e,} there 

may be associated a set of phases ^ = ty, • - • K 4'A> If ^ 'events «e occurring 

at their maximum rates, then no mora than w^^e^fj seconds can elapse before 

the next occurrence of e. . 

In addition, there may be one or more pending occurrence of any of the events 
on the event queue, so a set of tnHtfDy pending occurrences "■» 3(Q,, • • • , 0.) 

may be determined. These two factors alter the time due to preemption equation 
(5.12) as follows: 



* * A-/ 



v(wv-**) 



'mm**** 



+ *)*A 



(6.20) 



A good lower bound to this Is its solution without the Cfjjilng function: 



^^ 



k-i 


*K 


6 *mln%s*~M 






1-* 
A 







(6.21) 
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The solution Is again found by solving (6.21) for the Initial value f. and then 

solving (5.20) for T . using the previous value T. until they are equal. A sum- 

mary is given below as Algorithm 5.8, PHTIME. Note that If ^ " v m ^ 9 f^ **** °k " ° 
for all k, PHTIME computes the same value as PTIME. 



Algorithm 6.6. PHTIME(t, E^^, ♦, 8) 

Inputs: t, a time which represents computation time in the absence of preemption. 

E preempts' a 8et of ovents wh'ch can preempt the computation taking t 
seconds. 

+, a set of phases, one for each event In £_,„_._,_. 

ii..»( - fir OmJfipi9 

0, a set of initially pending occurrences, one for each event In ^iyeempfs* 

Outputs t^, the time taken in the worst case to perform a computation which 

takes t seconds to perform with no Interrupts. The worst case involves 
preemption by all ti*e events ft» E„ oei ^_ ts a* ofte# as possible, subject to 

the constraints of ♦, 0, and » ^ for each event. 

Method: 

1. Let W. -t. Let {e /f ■ ■ • , e.} be the events in ^■ DeoomD t s - Let 

{Wj, ' • ■ , W.} be the weights of the subcontroT structures initiated by 

the corresponding events. Then solve equation (5.21) for an initial value 
f . ; solve equation (6.20) repeatedly for f V using the previous value 

w w n 

of T. , terminating when they are equal. T. is the value to be re> 

r n-1 w n 

turned as t_*. 
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5,4.6: Task Execution Time with Preemption at Priorities > 

AJgortthm 5.5 gives a method for determining the maximum time that can elapse 
between the occurrence of an event e / and initiation of its subcontrol structure. 

This Is fairly simply done since while e^ is pending the set of events that can 

preempt it is static. Once Its subcontrol structure has been Initiated, however, 
only events in E^ can Interrupt; however, If any of these events does occur, 

any event in E wjn ^ will take priority over resumption of e^'s subcontrol struc- 
ture. 

This complicates the determination of worst case execution time (and laten- 
cies, as will be seen in the next section) for a task subset I of the subcontrol 
structure. Note, however, that if the set ^ /njU0 tt empty" (and* therefore the set 

of interrupting events is static), that PHTIME can be used to get the correct result 
in general though, the result must be found in stages, determining when I can 
be executed. The next algorithm determines the worst case time to execute a set 
of tasks I, contained In a single subcontrol structure, given the sets of events 
E anvays OTd E w**i.i/e for * ««d J^eir initial values of > and 0. It assumes that f 
has been Just initiated and then finds toe time t_ from initiation to completion of I. 

This is done by first finding how long W wWbe before all the pending interrupts, if 
any (based on 4 and 0), are processed and I can be resumed, Then the' earliest 
occurrence of an event In E |rf||W ^ marks the next preemption of I. At that point 

any accumulated occurrences of events in E wjn u will cause executions of their 

subcontrol structures to be completed before I can be resumed. This partitioning 
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of the total time taken to execute I is repeated until all of 1 Is completed. Note 
that the method does not require determination ef ah exact schedule for all the 
tasks in the control structure, although the exact times when I will be executed 
tkr& found. Algorithm 6.7, SCSTIME (for "subcontrol structure execution time") de- 
tails the procedure. Mote that this algorithm does not address the problem of 
determining execution time for a set of tasks which may require more than one in- 
vocation of a subcontrol structure. 

Algorithm 8.7. SCSTIMEtf. E^^rB^^^, #,0)' 

Inputs: i, a sublist of the tasks in a subcontrol structure. 
E^^aygi relative to «|, reinitiating event. 

E win_tlB> re,atlve to «l 

♦, phases for events in E^^ and E^^. 

0, tnitiaMy pending occurrences for events In tegfafa onfl E w/n tje • 
Output: t , the longest possible time to execute I with interruptions. 
*w/n t/e' * e flnal P naaes tor a " the events in ^ wjn tle - 
^winjtle* **** flna> nufflber °* pending occurrences for all the events in 



E wlnJle' 



Method: 



1 . Set l CJ|m ■ 0, the cumulative execution time for I. Set t - = 0. 



E always- Thte te 



2. Find how long I can execute before it is preempted by an event from 
. This is: 

t 2 - MINIMUM (* min (* k )-* k ) foraJle A c Ea/|vays (6.22) 



-86- 



Task Execution Time with Preemption at Priorities > O 



Section 5.4.6 



Go to step (4). 

3. Find how long I can be executed before an event from E^ 
preempts It; this occurs at time: 

t 2 - (least multiple of » m ^ fl (« A ) > i 1 for all e A * Eju^—) (5-23) 

4. If ^ cym * *2~*1 > W» * ** complete in this interyai; ^compute < p -t^ 
+ PI - leu,* compute 4 . w using equation (6.25) and substituting t 
for t 2 J compute ° W j n *j 6 using equation (6.24) and substituting t for t 2 - 
Return (t p , ^ //|We , 0^^). Otherwise as*.*- m ^ + 1 2 - 1 , . 

6. Set 8* 1 for the event from E^u-y- which caused the preemption. 
Some events In ^ w i n *j e may *J*o be pending: 



°*" 



wv 



6. Update phases for all events: 



'**' m +k m *wlnJUm 



(6.24) 



♦*-<2- 



W*A> 



W e A> ** aH e A "-<*****? E ^/«^e> (626) 



7. Find new value of 1 1 , the next resumption time of I: 
< 1 " *2 + PHT,ME <*' E a/ways U W"e' * « 



(5.26) 



8. Repeat steps (3) through (7) until termination of I is detected In step 
(4). 
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5.4.7: Latencies for Constraints aft Priorities > 

The worst case latency may be desired for a constraint which is satisfied by 
an execution of a subcontrot structure at a priority greater than 0. If the execu- 
tion which represents the greatest latency Involves two or more invocations of that 
subcontrol structure, the possibility of initiation delay must be considered as well 
as interruption delay. Each of these delays may involve a different set of preempt- 
ing events. 

There are thus several complexities to be dealt with in the general case, even 
with control structures meeting the restrictions of Section 6.4; however there are 
also several special cases with simpler solutions. An example is: wheri the sets 
E w/n_t/e and E /o$e tie ar8 era P t yj '* wW °e ahown how to make use of this 
simplification in a later section. 

Recall the notation of Section 5.2, where a subcontrol structure i was broken 
down Into components (fiy « v ■ ■ • , «„, 0%) relative to a constraint C, where the 

„ ■ . ,. .-. .-■■ ■ ■'■■:i ■ i -;i\ '•{;;--vv . "- : ■ ■■:■' 

•y's were critical windows and the fi f 's each contained one occurrence of C. 

The worst case latency of C in a control structure containing # at a priority 
level greater than zefoW found as fbttowS. t^t eV^be tne initiating event for *. 

There are two candidate time intervals which may be the worst case latency for C. 
The first, t- , is the maximum delay between occurrences of e. plus the maximum 

delay to complete *j with preemption. The second, t , Is the maximum time taken 

to complete * m , the most critical window of *, also with preemption. Either one 
may involve more than one invocation of *, and hence initiation delay. To show 
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that either ^ or t couid be the w©#et case latency for C, consider a simple ex- 
ample: 

OAVeDBCpey 



Example 6.1. 








where 












w mtu 


,(e1) = 


10 


sec. 




1*1 « 


1 sec. 








|Bj = 


dC «OG« 








\c\* 


leec. 








|D|- 


3 sec. 







The most critical window for the constraint (C) Is (C D C), with a weight of 5 
seconds. However, the longest time that elapses without an occurrence of C is 13 
seconds, which Is ^ , or ^(el) + |B| + |C|. if |D| were changed to be 16 

seconds, though, (C C) would still be the most critical window for (C), but now 

t is 1 7 seconds, which is greater than t- . 
m *1 

Thus the two candidate times must be computed and their maximum returned 

as 1(C). Note that since the entire control structure is repeated, the task list 

starting at fi 2 and wrapping around through fi* is a critical window, call it «-, and 

must have weight greater than fig, therefore fi 2 cannot take longer than It to exe- 
cute, and need not be considered as a candidate for 1(C). Furthermore, it might be 
thought that the weight of »^ plus the delay due to initiation of its second part, fi 2 , 

may in total be greater than the weight of an otherwise most critical window which 
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Is contained In i and hence has no Initiation delay associated with it. To show this 
Is untrue, it Is only necessary to show that the weight of «- with initiation delay 

must be less than t and t- , since the addition of delays due to Interruptions Is 

m p 1 

a monotonlcally increasing function of the time tatean without interruptions. 

Thus assume that « 4 Is not the most critical window of # for C (if it is* It will 

be considered by the algorithms and thus there is no need to justify Its exclusion). 
But if thlat is the case, then there Is a critical window « m in # with greater weight 

than «^; thus the time to execute «- Is less than or equal to 

In the absence of Interruptions. But since (a J Is *"\* m \, equation (6.22) is s 

w max^ e ^' Th,s in tum te ,oss *""" *«' wn,cn '"ctades f^e.) as one of its sum- 
mands. Thus it Is sufficient to find the maximum of t- and t 

Consider the computation of t . First the most critical window must be found 

m 

for C in + using the algorithm for iterative control structures, ILATENCY* Note that 

In this case since the entire subcontrol structure gets repeated, the head (0.. ) of 

(#)* containing C cannot represent the worst latency for C by itself (without initia- 
tion delay); there must be a critical window of greater weight which includes j9 1 

aa its second occurrence of C. 

Therefore ILATENCY will return 1(C), the weight of the most critical window «_ 

IB 
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in {*)*. ILATENCY also returns start_index, the Index In f of the first task of « , 

s* 

and num_tasks, the number of tasks bi'e_. Knowing this, it can be determined how 
many times e . , the initiating event for #, must occur during *-,*» execution (i.e., by 
knowing how many copies of * are Included in *_). Partition «_ Into the subfists 
i m m * m m ' " ' • * m )» where each m m is a portion of * m which is contained in (a 

single copy of) #. Since t is the longest possible time to execute « M , It must 

be assumed that aR the interrupts happen Immediately after Initiation of e and 
continue at their maximum rates, whBe the Initiating event e^ happens at its 
slowest rate. 

Figure 6.4 shows the time line for part of a sample execution of a critical win- 
dow « m which is not contained by a single copy of *. 



| 1 | 2 | 3 1 4 1 — »----|- — a- 

• ■ # e m e « 

p starts m m p m 
occurs t 1 occurs 2 

starts ends second starts 

time 



Fig. 6A Partial execution of a critical window «. 

m 

In the worst case, the initiation delay of interval (4) will be the maximum possi- 
ble, with the constraint that Interval (3) must be at its maximum too (greatest 
amount of time lost to interrupts). Therefore the intervals (t) and (2) must be 



-90- 



Latencies for Constraints at Priorities > Section 6.4.7 

computed at their minimum, i.e. no preemption. Thus interval (1) Is assumed to be 
zero, and Interval (21 te f#| - h^ |. This may gh/tf »^rt Inflated Upper bound by 

lengthening interval (4); if it is known in a particular case that preemption must 
occur during intervals (1) and (2), an adjustment can be made In the phases of the 
Interrupting events at the beginning of interval (3). 

As was previously stated, it is assumed that the worst case is when all events 
occur right after « m starts, so the lehgtfi of Nerval fa), t (3 j, is found from 

8CST,ME( *m 1 ' E a/ways' E w/n.We'*' 0) ***"> C a/ways and E w/n.t/e are drt flTv 
mined relative to e #f * *<0, , . . , 0> and O « <i, ".? . , Wfof afthtf^evWrrts. 
Oitce the interval times t (1 j, t (2) , andi^ are determined, t " is fourfd by: 

lf *(4) * °> 'there Is an Initiation delay Which must be factored Into the solution. 

At this point andfher decision must be made which affects the tightness of the 
upper bound determined by the algorithm, burlng interval (4), any of the events in 
the coftfrolnstructure *g»«Vthsn ^,iaav3get ? e^itfrol, and there may be arbitrarily 

com P| e X bfeKridno out an^ong the different sets <rf events due to the exact order of 
occurrences; I.e., to get the true picture, the sets E^ s , E^ /fl ,. and 

*/oseJle re,ative to wen/ event must be considered, since the reference point 
provided by knowledge that e^ was pending has been lost. This makes finding an 
analytic solution for the values of * and at the end of Interval (4) quite comply 
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cated, and two alternatives are provided here instead. Note that the relative Im- 
portance of this is dependent on the relative ate* of interval <4); In the extreme 
case, if it is zero, then there is no problem at all. 

The simpler method (and the one used here) is to assume that all events in 
E a/ways and E w/n tie ° et Dlocked out during interval (4), and thus their **s and O's 
get updated accordingly. This will provide an upper bound which is high by the 
amount of execution of preempting tasks which could have taken place during inter- 
val (4) and wiR now instead be added to the preemption delays of the next inter- 
val. 

Unfortunately, this is no* the oniy complication, in the worst case, en event 
from E JMfLt/e m,flht ■•* contro, J" 8 * before the end of interval (4), and Initiate a 
subcontrol structure which could not be preempted by e .. The event e. In 
E tose_i/e which Initiates a subcontrol structure that runs foV the longest time 
without being preempted by an event In E^ or ^ winJi0 (given their 4's and 

O's at the end of interval (4)) is chosen, since once it gets preempted it has less 
priority than e^ by definition. Let the length of this time be t,, and tiien the time 

""*" "m 2 8tarts te &*" bv Pmim ^ri E Mm^ U ^nJi^- +' 0) ' Tn * ♦'« and 
O's are updated and the process is repeated as from the start of * m , terminating 

when the end of «_ is reached. 
m n 

The alternative method is to determine an exact schedule for Interval (4). 

Then It wiH be known whether or not an event from E/^ tl0 can get control and 
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keep it past the end of Interval (4), and the exact #'s and 0"a for all the events 
can be determined. This is the method of choice if the initiation delay is known to 
be significant. 

The interval t- is measured on a sHghtly different «me line: 
¥ 1 





e 


* 


fi 




e 


fi 




i 


1 


1 




# 


1 




occur 8 


1 


1 




occurs 


2 






starts 


ends 




second 
tJme 


starts 



Fig. 6.5. Partial execution of fi- . 

To find tp , the execution of fi^ is broken down into parts which are contained In a 

single copy of f , Just as was done for a m . Here the worst case Is when all inter- 
rupts happen at the beginning of interval (1) and continue at their maximum rate, 
since the length of interval (0) is fixed at 'fl^^Ce^); this gives the greatest delay 
during interval (1). Interval (1) is thus the maximum initiation delay for f with 
preemption, including the possibility of an event from E /ose tie getting control just 

before e^ happens and causing further delay as previously discussed. The times 
of the remaining intervals are found as was done for the m *s, computing the initial 

t's and ITs appropriately. 

This procedure is detailed in Algorithm 6.8, LATENCY. 
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Algorithms.*: LATEMCYtC, p) 
bipttts: C, a constraint 

p, a subcontrol structure containing at the tasks in C, in a contro) struc- 
ture meeting the restrictions of Section 5.4, and where the worst case la- 
tency of C is known not to be i nfcata by equation (6.1 1), 

Output: KC), the worst case latency of C in the control structure containing p. 

Method: 

1. Find KC), start-index, and num_tasks by executing ILATENCY((p)», C). 
Let « m be the critical window starting at start-index and continuing for 
man-tasks. 

2. Rnd the subfists of * : (m , « ,••*,«_ ) where each «_ is 

the completely contained in a single copy eTp. rf the number of tasks in 

p is A. then m * pfstartjndex] through pf*], «_ through * = p, 

1 m 2 W n-1 

and "m " *t"»] through p[num_tasks - A<n - 2) - (A - startjndex + 1 )]. 
it 

3. Since the worst case involves maximum Initiation delay for p, assume 
Intervals (1) and (2) (see Figure 6.4* ejapee without preemption- Thus 
\^ * and t (2) * f*j - f« w % • B « f V" ^CD * SzY ** ** * t * rt '** brt ® rv « J 
(3). 

4. Find the sets E^^^^, and E^ ffJf ^ relative toe # . Set + = and Q = 

f for an events fti these sets. Fttd the set E^^ relative to e . . Set 

^ =0. Initiate the counter / * 0. Repeal steps (6) through (7) until 
n> 

the end of m is reached in step (5). 

& Set / * / ♦ • i. Find t^ « t p , which Is returned by 
SCSTIMEC^, Ea/|wvs , E mhlJU9 , 4, 0). Set t^ « t^ ♦ t^. Set * and 

for the events hi E^ f/e to the values 4^ „ e and * wlnJlm returned 
by 8CSTMIE. If t » a, go to step fl» where t, la computed. 

6. At the end of t^ 3 j, since m m was in control, none of tiie events in 
E atways **• P« n * no > **«*» set « O 
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♦a-*, 



m 



to 



*/»//,<•* > J 



*mi n im k yior •**■•*«« « A * { E a/ ways } ( 528 > 



7. Let t (4) « 'ma^Ce^) - t (3) - ^. if t^ 4) > O, there Is an initiation delay 
and the following must be done: 

a. Update * and for each event e^ in {E -/|| ^ s U E^ f/a >: 



°*- 



SSL 



*K 






(5.29) 



(5.30) 



b. Find the event e ; e E /oae (/# which initiates a subcontrol 

structure that can run the longest before (or without) being 
preempted by an event in {E^^^ UE w//} tfe } ; this can be done 

by considering each event In JE tm9jUm M Jurn„ Let ^ be the 
time which elapses past the end of Interval (4) due to e.. 



c. Find tbet initiation delay of « 



ffl 



/+1 



Way = PHTlME(t e/ , {E^^ U £„,„ _ t/e> , 4, 0) 



d. Sett 



+ t/„x + t. 



a. Set 8^ - 0, and: 



(6.31) 



♦*-*« 



m 



m 



*mln iB k y } 



WV 



for all events e A in {E.,^ UE w/ffJ/e }. 



•• Set V"Way 



If t (4) Is zero, set ♦,-♦,♦ t (3) - w^e,). 



(6.32) 



-86- 



Latencies for Constraints at Priorities > O Section 6.4.7 

8. Find tj ; find ft^ of (#)* by scanning until the first occurrence of C 

has been scanned. Divide #, Into subfet* as was done for « m in step (2), 
getting as a result tf, , , ■ • • , ft ), where this n may be different 

from the /> obtained for «. 

9. Refer to Figure 6.6. The time of interval (0), % )» te 'ma**®^' **" 
aume all events in {E -/|irays UE^ flJfe } occur at the end of this Interval, 
and continue at their maximum respective rates. Thus set 0=1 and * * 
for ail these events. Let T^ .'-'^j? ,t«V = 0. Starting at step (7b), ex- 
ecute Just as for « m , substituting y f or t^ , and 0., for « m . 

10. Return MAXIMUM^ , t # ). 

1 m 



ff.6: Special Cases and Extensions 

There are many special cases which result in much simpler algorithms. Each al- 
gorithm presented In the previous section Is directed towards a subset of control 
structure types which contains the previous subset and some additional control 
structure types; It is seen tiiat in general, as the number of different types in the 
subset increases, so does the complexify of ^e resulting algorithms. 

As an example of another important special case, consider finding any of the 

real-time properties for a subcontroi structure whose sets E, „ and E , , 

tosejtie mrinjtie 

are empty, e.g., as would be the case In a control structure containing no event 
coupled lists. Now all of the complications due to having the set of preempting 
event variables change dynamically drop out - the statically determined set 
E a/ways te **"* ori,v ••* *"** "'"V Preempt, and by definition It can always preempt. 
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The simplifications this Introduces are substantial; take the most complex of the 
algorithms of the previous section, Algorithm 6.8, UtlENCY, for example, In step 
(6), SCST4ME can be replaced by the simpler PHTIME. There may still be an initia- 
tion delay t^ 4 j, but there is no longer tfte possibMty of ah event from E /<we tf 

getting control and prolonging the initiation time. 

As far as extensions to the algorithms go, there are two principal areas to con- 
sider: one Is the determination of algorithms for real-time properties not discussed 
here and which are germane to a specific application, and the other is the lifting of 
tiie restrictions of Section 6.4 to allow any representable control structure to be 
analyzed. Since the first area requires an application relative to which suitable al- 
gorithms can be developed, only the second area will be covered here. 

The difficulty involved In lifting the restrictions of Section 5.4 varies consider- 
ably from one restriction to the next, and hence they are discussed here one at 
time. The following discussions are not intended to be the final word on the topic, 
nor are all the details supplied for a particular method of lifting each restriction. 
Instead, the intention is to point out the difficulties involved In each case and to 
make suggestions as to how they might be overcome. 

5.6. t» €xtomel Termination 

Recall that there era two types of Iteration, In effect, that can be applied to a 
subcontroi structure; local and global. If a subcontroi structure is locally cyclic, it 
means that that particular subcontroi structure executes Indeftartely, without requir- 
ing reinitiation by its Initiating event. This is equivalent, then, to having an event 
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which Initiates a subcontrol structure with infinite weight. If, instead, It is part of a 
globally cyclic control structure, then it too wiM he repeated Indefinitely, but only 
one time per Initiating event occurrence. Both of these types are avowed under 
the restrictions of Section 6.4, because the weights of the Initiated subcontrol 
structures are fixed, even though they may be infinite in the locally cyclic case. 
However, there is the potential for a subcontrol structure which has infinite (and 
thus fixed) weight with no external termination to have varying weight in the pres- 
ence of external termination. Thus the delays encountered In the execution of 
lower priority control structures due to Interrupts which Initiated <abort cs>'s 
(those which may be externally terminated) will vary according to how long the 
<abort ca> executes before ft gets preempted. An upper bound on this time can 
be found if a good value Is known for f max of the terminating event; if there is 

more than one such event, the minimum of their maximum periods may be used. 

Note that this also complicates the determtoatton of toad factor (equation 
(6.11)), since that depends as wen on having a known upper bound for the weight 
of each subcontrol structure. 

6.6.2: Restart Control Structures 

This is another case which may lead to variable subcoMtrot structure execution 
times. Every time a {restart cs> gets preempted, the time of lt» current execution 
is extended by its nominal weight in the absence of preemption; ft is essentially 
the opposite of external termination. Thus a <restert cs> needs a non-preempted 
Interval equal to Its nominal weight in which to execute. To find whether such an 
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interval exists, one must see whether the phases of all the events in the sets 
£ aiways and ^wJn tie ro ' at,ve to tne <restart cs> can be adjusted so that it gets 
preempted at least once every ]<restart cs>| - < seconds. This can be either very 
simple, as in the case where there Is only one event that can preempt the <restart 
C8>, or very complex, if there are many events and their interrelationships must be 
considered. 



6.6.3: Codestripping 

This Is somewhat simpler to handle. If one of the interrupting events initiates 
a <codestripped cs>, then the delay it causes Is simply Its nominal weight divided 
by the number of codestrlps, e.g. the weight ef (A/6) Is Jusf }A|/5. If the tasks 
whose execution time is being measured are codestrlpped, though, it is as if they 
were preempted by an event with variable w mln - to get this effect, a dummy 

event can be substituted for the integer which tells how many codestrlps there 
are, and its phase can be adjusted every time the <codestripped cs> Is resumed 
so that it will cause preemption at the time when a single codestrlp would have 
finished. 

6.6.4: Non-Preemptible Tasks 

L«t # meas be a subcontrol structure whose real-time properties are being 

measured. Then if a subcontrol structure of higher priority than f____ includes 

non-preemptible tasks, the effect on i m99Si Is unnotlceable - these tasks would 
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have been executed to completion anyway before ^ was resumed. If alt of 

/HOBS 

*meas te non-Preemptible, then its computation time need not include the effects of 

those interrupts which cannot preempt it, and the sets Ej^ and * win tie can 

be adjusted accordingly. If only a part of ^ is non-preemptible, then the **s 

and ffs of interrupting events must be updated when the non-preemptible part has 
been executed. If a subcontrol structure of lower priority than if* is non- 

preemptible, then if the Interval #^,3^ includes an initiation delay, it must be in- 
creased by the maximum amount possible due to execution of tasks which e . can- 
not preempt. This can be handled simHarty to the case where an event from 
E /o*e tie 9ets control J" 8 * before e . occurs. 



5.5.6: Stopping the Flow of Control 

This is another case which may result in effectively varying the weights of 
subcontrol structures and hence the delay due to preemptions which include their 
execution. It has some similarities to external termination; consider the example 
given in equation (6.7), repeated here: 

««A*/e1)B)/e2)C)* 

The problem is that the effect of the delay in executing A due to el's occurrence 
is dependent on the period of e2 - hence the similarity to external termination. 
The difference is that the minimum effective weight of B is still JB|, since an oc- 
currence of e2 before the end of B preempts B, but leaves the remainder of B to 
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be resumed once C is done. 

Thus the techniques for external termination can be applied bare, with the con- 
straint that the minimum weight of a aubcontrol structure Is stHf its nominal weight. 

5.6.8: Constraints at More than One Priority Level 

To be able to consider the worst case latencies of constraints whose member 
tasks are found at different priority levels and thus in different subcontrol struc- 
tures is a difficult problem. To determine this, the executions of tasks at lower and 
higher priority levels can no longer be lumped together and treated as a delay, 
since at the very least it must be known when every task which occurs In the con- 
straint Is executed, regardless of what its priority may be. Thus algorithms of a 
very different sort from those in the previous sections are probably required, and 
the possibility of simulation to determine an exact schedule may provide a starting 
point 

6.5.7: Finite Event Queues 

If only a finite number of event occurrences can be remembered, and this 
number is small enough so that some event occurrences are ignored, then from 
*meas' 8 P '"* ** v,ow » tne delays due to preemption computed previously may be 
too high but cannot be too low. The equations which determine the time lost to 
preemption must be adjusted to Include a maximum value of 0. 

When computing initiation delay, it must now be seen whether, in the worst 
case, the Initiation delay may be prolonged due the initiating event's occurrence 
being ignored. 

-to*- 



6: Conclusion* and Directions for Future Research 

A new notation fees bean given which represents reaKime control structures at 
a high (task and event) and Implementation-free level, Including sequencing, itera- 
tion and preemption as primary constructs. The notation can represent convention- 
al single and multiple level Interrupt structures as weH as non-traditional ones 
where branching of the preemption structure is generalized. A total priority order- 
teg may be described, or arbitrarily many events and subcontroi structures may re- 
side at the same priority level. An algorithm Is given for determining the preemption 
relationship for any <event, task> couple in the control structure, as well as a com- 
pletely deterministic method of selecting a task for service if several events with 
arbitrary priorities are pending (possibly equal). It may be interesting to consider 
the modifications necessary to the algorithms if it is assumed that the processor 
chooses at random from among ail the pending events of the highest priority. 

Additionally, notation is given for representing task termination by external 
event occurrences (as opposed to temporary preemption), describing whether a 
control structure should be restarted from its first task or resumed from the point 
of preemption, codestripping, and masking of a set of interrupts while any given 
task Is executing. It is shown that due to the assumed transitivity of the 
"preempts" relation, the sets of events chosen for these special cases might 
necessarSy include other events not explicitly mentioned. 

The notation Is compact, and provides a convenient format for conveying a tot 
of information about the control flow relationships among the members of a set of 
tasks. A complete BW= specification is provided, and a parser can be (and has 
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been) constructed using any of a number of extant complfer-eompllers which accept 
BNF specifications. 

Classes of representabie control structures ire given, typed by the topology 
of their control flow graphs. It is shown that partial as Welt as total orderlngs of 
tasks and events can be achieved through the use of the event coupled list, which 
Introduces forks into the control flow graph. A method for recursively constructing 
a multiple priority level controi structure of the traditional type Is given. The dis- 
tinction is made between a control structure which supports a processor priority 
and one which aetuafly has only a sirtgie fevei of httiimipts, oven though there may 
be a set of several interrupting events which are ordered among themselves. It is 
shown that white In general the need for this type of control structure is perceived 
to be strongest in situations where representation of periodic events and task exe- 
cutions prevails, apertodie control structures are represehtaWe. However, a true 
tree-shaped mterrupt structure cannot b« achieved due to the transitivity of the 
"preempts* relation, in addition, while iteration can be applied to any closed or 
basic control structure, a back arc cannot originate from the middle Of one event 
coupled list and terminate in the middle of another, This is hot felt to be a serious 
rastPietion, howeven sJnc^'WHi likely that groups of tasks In a SuDcontrbl structure 
are related and expected to be executed as a block. ?? ' 

The second naif of the thesis concentrates on describing the sorts of reat-time 
properties which may be of interest to a user of any reaf-time system, and demon- 
strating how they can be measured for control Structures representabie using the 
notation presented here. The worst case latency of a constraint is found to be a 
property whose determination involves computation of several other properties as 
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subroutines. The difficulty of finding an upper bound on task execution tkae Is dis- 
cussed, although without this knowledge it Is doubtful that much further analysis of 
value could be performed. Additionally, bounds on the maximum and minimum period 
for each event are needed. The algorithms, reflect reality, in that If these periods 
are not known, it will be difficult to forecast re*»-time performance for the control 
structure. . .v 

Next several algorithms for measuring latencies are developed, each handling a 
larger set of control structure types, up to a level which includes the entire baete 
framework of sequencing, iteration and preemption. Along «*e way, it is shown how 
to determine if a response time might be infinite, and it is assumed that this is done 
before attempting to use any of the algorithms for measuring the various time inter- 
vals. An algorithm is given which determines the toss of time due to preemption if 
the set of preempting events Is static, and by using it it is shown how to determine 
the latency of a constraint contained |n a priority subcontrpl structure, and the 
worst case initiation delay for an event at a given priority levei The worst case 
assumed here is the occurrence at the beginning of an interval of aH interrupts, 
and their reoccurrence at theJr individual maximum rates. However, an algorithm is 
also given which determines preemption time tt the phase of each event is known 
at the beginning of the interval being measured. 

The effects on these algorithms of adding control structures containing each of 
the restricted Items of Section 6.4 is considered; further investigation is needed 
here to uncover the details of the problems which are pointed out. Another useful 
thing would be to develop analyses based on & probabiHstic model rather than; on 
the worst case; e.g., what is the probability that • aiven constraint will have a la- 
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tency of no more than n seconds? Finally, an important result would be the 
development of a general algorithm which could determine the latency for any of 
the representable control structures. The difficulty of such a task should not be 
underestimated; indeed, in the words of Nlklaus Wirth: 

It does not appear feasible at this time to postulate any generally 
valid and at the same time practically useful rules for the determi- 
nation of execution time bounds for systems using processor' shar- 
ing. [Wirth 77b] 
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Appendix A: Summary of BNF for RaaJ-tlme Control Structures 

<oorrtrol structure> ::= <basic cs> j <closed cs> J <iterath/e cs> 

<ta«k W> ::= <lotter> ] <task kf> <alphanumeric> 

<tetter> ::= A | B | C | ... J Z 

<alphanumerie> ::= <lettor> J <<figit> 

<diglt> ::= | 1 | 2 | ... | 9 

Cbaalc cs> ::= <task> j <basic cs> It <task> | <basic cs> t 

<task> ::= <task id> J <non-preemptible tid> f <abort tld> 

< closed cs> ::* ( <basic cs> ) J ( preemptible cs> ) j ( < closed cs Hst> ) J 
( <dosed cs> <preemptible cs> ) | ( <ciosed cs> <baslc cs> ) J 
( <restart cs> ) j <non-preemptible closed cs> J <abort cs> 
< closed cs flst> ::= <ciosed cs> | <closed cs Hst> <closed cs> 
<tterative cs> ::= <basic cs>" J <closed cs>* | <basic cs> <lterative cs> 
<preemptible cs> :;= <control structure> / <event llst> J <codestripped cs> 
<event var> ::= e<integer> 
<integer> ::= <cHgit> | <integer> <digit> 
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<event list> ::= <event var> | Kevent coupled flst» | 
«event coupled Hst»* 

<event coupled llat> ::■ <event var>: <control structure> | 

<event coupled liat> '|* <event var>: <control structure> 

<flon*preeiaptlble ttd> ::« <<task> | *«ev ltet»<task> 

<nor>-prearaptlble closed e»> :t » '< closed cs> | «<<ev list»<closed cs> 

<ev Het> ::« (event vaf> | <ev Hat>,<event var> 

<«bort tld> ::« *<taak> J 8«ev l»at»<task> 

<abort cs> ::« 8<otoeed ca> | 8«ev Uat»<ctosed ca> 

(restart ca> ::« > <baafe cs> f > «ev flst» (basic cs> 

(codestripped ca> ::■ <baalc cs> / (integer> 
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